Artifacts in sound played by wavplay about wav.jl HOT 8 CLOSED

wavplay uses the AudioToolbox framework on the Mac. I'm not sure what is causing the buzzing sound on your system. Do you still hear the buzzing sound if you install the pulseaudio libraries (and use libpulse-simple.dylib)? The WAV package will use the pulse library when it is found in the system path. I test the pulse audio path by using brew to install the package (brew install pulseaudio).

from wav.jl.

closing due to lack of follow up

from wav.jl.

I can definitely reproduce this problem on my MacBook Pro (Retina, 13-inch, Early 2013) with macOS 10.15.6 Catalina, using both Julia 1.4.2 and 1.5.0 and the current main branch of this package.

The wavplay output has under macOS a clearly audible additional buzz that the same waveform played with afplay lacks:

using WAV
fs = 48000;
t = 0:1/fs:2;
f = 100 .+ t .* 600;
s = 0.1 * sin.(2π * cumsum(f)/fs);
wavplay(s,fs)
wavwrite(s,"test.wav",Fs=fs)
run(`afplay test.wav`);

Something appears to corrupt the waveform played by the AudioQueue backend. Perhaps some samples being added or dropped at high frequency?

Sadly, Apple's Audio Queue Services online documentation is hardly illuminating. Do you know any better documentation for the API used here?

from wav.jl.

Could you please reopen this issue until it is fixed?

The following patch prevents that enqueueBuffer duplicates each 512th sample by resubmitting the last sample of each 512-sample block again at the start of the next 512-sample block:

diff --git a/src/wavplay-audioqueue.jl b/src/wavplay-audioqueue.jl
index ded2dff..8188823 100644
--- a/src/wavplay-audioqueue.jl
+++ b/src/wavplay-audioqueue.jl
@@ -199,7 +199,7 @@ function enqueueBuffer(userData, buf)
     idx = ntuple(i -> i > 1 ? (1:size(userData.samples, i)) : (userData.offset:end_offset),
                  ndims(userData.samples))
     AudioQueueEnqueueBuffer(userData.aq, buf, getindex(userData.samples, idx...))
-    userData.offset = end_offset
+    userData.offset = end_offset + 1
     userData.nBuffersEnqueued += 1
     return true
 end

This off-by-one error explains the buzz reported.

from wav.jl.

Before I prepare a PR, I'm trying to more fully understand wavplay-audioqueue.jl. It looks surprisingly complicated. Where did that originally come from? Why are there Doxygen-style comments? Is there some C or ObjectiveC example code that you used as a template?

from wav.jl.

This code is based on an objective c version that I wrote previously. There is not a lot of documentation online (at least not when wrote this code). I cobbled this together by reading the system headers, which included some documentation.

There is a Core Audio book now, but I wrote this code prior to acquiring a copy. I vaguely remember referencing the author’s blog when I could not piece something together.

https://www.oreilly.com/library/view/learning-core-audio/9780321636973/

Core Audio basically has an audio thread running that this code feeds. The system manages the memory in an opaque manner in the name of efficiency.

from wav.jl.

While my + 1 patch above fixes the problem for mono output (Array{Float64,1} waveform data), there are still very audible clicks when I try stereo output (2-column Array{Float64,2} waveform data), e.g. after adding a second channel to the above example with s = [s reverse(s)]. I've now ordered the book from a local library.

from wav.jl.

Sorry for my disappearance (extremely heavy semester), and thanks for fixing the problem. I was also having issues with #89, but installing 1.0.4 solved both problems.

from wav.jl.