Audio stutter

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.

TIA

--
Regards 
Dave Saville
Reply to
Dave Saville
Loading thread data ...

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 --

Reply to
Pete

Hi Pete

I started using aplay and it was so bad I switched to pacat.

--
Regards 
Dave Saville
Reply to
Dave Saville

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 --

Reply to
Pete

aplay usually throws underuns and often seems to leave the audio in a not working state. With either if I generate at other than 44100 I get nothing at all out of the speakers.

--
Regards 
Dave Saville
Reply to
Dave Saville

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 --

Reply to
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.

--
Regards 
Dave Saville
Reply to
Dave Saville

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)

Gordon

Reply to
Gordon Henderson

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:

cat test.wav|aplay

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 --

Reply to
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 it.)

May be unnoticeable except for things like speech synths.

-- Pete --

Reply to
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.

--
Geoff Clare
Reply to
Geoff Clare

default Playback/recording through the PulseAudio sound server sysdefault:CARD=ALSA 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.

--
Regards 
Dave Saville
Reply to
Dave Saville

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.

---druck

Reply to
druck

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.