I am playing with perl on a raspberry pi with some generated stereo
piped to pacat. This is for a larger project but for this I just have
a sine wave that moves across the speakers for a few seconds. It
stutters so I was wondering what might cause this as things like
mplayer work fine.
I thought it might have something to do with piping each sample to
pacat so I tried building the whole 3 seconds stream and then sending
it but it still stutters, mainly at the beginning.
Can one write to the raw device? There is no /dev/audio.
AHAH! This ties in nicely with what I found a few weeks ago.
It looks like pulseaudio is not working properly on the Pi.
I wanted to use espeak, which uses pulseaudio for its output, and
encountered much the same stuttering you describe. OTOH I can
pipe the espeak output stream to aplay, and I get clean audio.
[Well... almost (:-/) For some reason aplay seems to chop the first
half second of the speech. Strangely this also happens if I write
the speech to a file first, and play that with aplay, but if I copy
that exact file to my laptop, the whole sentence plays! Other wav
files don't seem to show the effect. Odd.]
If you have standard Raspbian, you should have aplay, too (as it
comes with ALSA). Try piping to that instead of pacat, and see what
happens. (I uninstalled pulseaudio [I forget what it seemed to be
interfering with] so I can't try pacat myself right now.)
I searched the rPi foruns a bit at the time, and saw others had
encounterd the problem, but no solution as yet. I started to dig
into it myself, but I haven't much idea where to start looking.
-- Pete --
Huh... I haven't had any problems with aplay except for the aformentioned
missing start on the one file. (Though I have to admit I haven't used
audio much on the Pi yet.)
What difficulties did you have with aplay? pacat works for you
otherwise? (Guess I'll have to try reinstalling PA -- wish I could
remember the exact conflict, but it stopped something else working.)
-- Pete --
Huh, again... (:-/) I don't seem to have any such glitches.
I've just copied a bunch of wavs over to the Pi, with sample rates
ranging from 8000 to 48000, and they all play perfectly. Haven't
been able to hang the audio yet, either. Must be something different
in our environments. I'm using HDMI, if it's relevant.
-- Pete --
I think there is a world of difference in telling aplay/pacat to play
a previously, correctly, generated wav file and trying to generate on
the fly and play it. I am using perl on Raspbian and using the
headphone socket to drive the speakers.
FWIW: I have a program (in C) that generates sound samples and plays them
"on the fly". Seems to work just fine (given the limits of the cpu grunt
avalable to create the samples in the first place), but I can reasonably
well synthesize the old BBC Micro's SOUND and ENVELOPE commands and play
the resulting waves...
However I've only tried HDMI so-far and I'm using the SDL library to do
the playing... (Which I think uses ALSA)
I'm finding nothing but counterexamples at my end, too, I'm afraid.
Piping a wav file to aplay via cat ought to be fairly equivalent to
actually generating audio real-time, I'd think (provided the problem
is not actually in the generator). If I do:
it works fine, even if test.wav is say 8kHz.
I generated a raw audio file with sox, and did:
cat test.raw|aplay -fS16_LE -r8000
and it was just as flawless.
And as I mentioned before, I was getting stuttering with espeak when
driving pulseaudio, but if I piped the output to aplay instead, it
was clean -- aside from the strange missing first half-second.
In a slightly different area, I use Csound a lot on my various machines,
so one of the first things I did was to download the rPi version.
I was very disappointed to find that I got very badly broken audio
with any sample-rate higher than 22050, so I put it aside -- blaming
the Pi's slow CPU. Last night, though, I thought wait a minute...
what audio system is it actually using? I checked, and by default
it outputs via portaudio. I switched it to direct alsa output, and
voila! Nice clean 48kHz sound!
It seems to me that the Pi still has some problems with the various
audio schemes. [I've always felt that audio in Linux was pretty much
a nightmare anyway, with OSS, ALSA, PulseAudio, PortAudio, Jack...]
But as ALSA is what actually supplies the drivers for everything,
using that ought to be the cleanest.
My *suspicion* [only] is that PulseAudio may be the true source of
your problems. It was all very confusing at the time, but my vague
memory is that aplay was indeed one of the things that stopped
working (being fine before I started playing with PA), so I said
"Heck with it", flushed PA, rebooted, and it's been fine since.
-- Pete --
Just a little more on that phenomenon... I've done some more detailed
checking, and I overestimated the length of the missing start.
It seems to be there on all files (or streams) -- it's just hard to hear
on, say, a music file. It's not quite constant, but varies between
~0.2..0.3 sec (I used an audio editor on another machine to reproduce
May be unnoticeable except for things like speech synths.
-- Pete --
If pulseaudio is running, it sets itself up as the default ALSA
output. If you make aplay use the hardware directly instead it
should make a difference.
This is based on experience on a Debian wheezy system, but Raspbian
presumably has pulseaudio and ALSA configured the same way.
Check what "aplay -L" says the default is.
Playback/recording through the PulseAudio sound server
bcm2835 ALSA, bcm2835 ALSA
Default Audio Device
HaHa - "aplay -D sysdefault" fixes (most) things. Plays a generated
sine wave at 8K sampling but the same sine wave at 44100 throws
"underrun!!! (at least xxx ms long). Thank you so much.
There isn't a huge difference, audio works by preparing buffers which
are then passed through to the sound hardware. In one case the buffer is
filled by reading a audio file from disc, and in the other the buffer
contents are generated by an algorithm.
Its far more likely that filing system latency will cause buffer under
runs than computing an algorithm, unless its hideously complex.