[Portaudio] Some problems with ALSA and some patches to fix them
Werner.Dittmann at t-online.de
Sat Jan 2 04:01:10 EST 2010
I use the standard ALSA lib that is included in openSuse 11.2,
this is libasound.so.2.0.0. I had a similar report about very bad
sound quality from a developer who uses a Debian system.
Am 01.01.2010 20:28, schrieb Richard Ash:
> On Fri, 2010-01-01 at 12:40 +0100, Werner Dittmann wrote:
>> currently I'm working on a project that uses portaudio to be able
>> to uses sound on a number of OSes (Linux, Mac, Windows). During
>> development and tests on my Linux system I discovered some problems.
>> The system I use:
>> Linux OpenSuse 11.2, 64bit on an AMD dual core CPU
>> Sound chip and drvier: CMI8738 MC6 PCI
>> On my system and may be on Debian systems the ALSA "default" device is
>> mapped to the plain ALSA "dmix" device which supports 48000 _only_,
>> no buffering etc.
> What version of ALSA lib are you using? AFAIK this hasn't been the
> default setting in ALSA for about 5 years, default does get mapped to
> dmix on device 0, but dmix supports on-the-fly resampling in software,
> multiple stream mixing and so on.
Well, plain dmix does not support on-the-fly resampling in software
according to the comments and documentation in ALSA's dmix device source.
Also ALSA wiki explicitly says: to do resample with dmix
one must wrap dmix with the plug device _and_ provide the necessary
parameters in the associated slave to dmix. The plug device performs the
> I will have a look at and play with your patches, but I don't think that
> users should need a .asoundrc file to enable resampling with anything
> like a current ALSA lib (since 1.0.9 according to the documentation),
> unless the distribution has done something drastic to ALSA's default
> configuration (/usr/share/alsa/alsa.conf).
Well, I checked the distribution's alsa configuration for my sound chip in
/usr/share/alsa/cards/CMI8738-MC6.conf. Here the definition for default:
# default with dmix/dsnoop
@args [ CARD ]
strings [ "dmix:" $CARD ]
strings [ "dsnoop:" $CARD ]
To me (I'm not a real in-depth ALSA expert) this defines the
plain dmix as playback device and plain dsnoop as capture without
/usr/share/alsa/alsa.conf includes the chip's specific definition
file. During debugging I put in some printf in portaudio's ALSA code
and the output confirmed that the "default" setting really uses plain
Anyhow, the problem with the capture end-less loop was due to an
overrun condition. The sequence is as follows:
- read calls waitForFrames
- WaitForFrames checks available frames (GetAvailableFrames) that
- WaitForFrames enters Poll while loop for capture
- poll returns
- WaitForFrames calls EndPolling does not detect an error, sets PollCapture
to false and xrun == 0. EndPoll does not check for available frames.
- WaitForFrames checks for available frames (GetAvailableFrames)
that detects an overrun and sets xrun (to me it seems that this overrun
event was the reason to return from poll and EndPoll just checks
the event source, in this case the capture device).
- WaitForFrames calls handleXrun that recovers the capture stream
and leaves it in PREPARED state
- return to read
- read did not check xrun, frames available == 0, loop, calls
- eventually WaitForFrames enters poll while loop. Because of its state the
ALSA system does not report any event and the poll triggers the
- endPolling does not set xrun, (revents is 0) and does not set
pollCapture to false and the while loop never terminates.
> Portaudio mailing list
> Portaudio at music.columbia.edu
More information about the Portaudio