[alsa-devel] emu10k1 ALSA/jack problem

Takashi Iwai tiwai at suse.de
Tue Aug 14 19:06:37 CEST 2007

At Fri, 10 Aug 2007 12:10:45 +0100,
jamesmstone at gmail.com wrote:
> Dear All,
> I am currently working on an audio program (aldrin) which uses
> libbzub driver
> http://trac.zeitherrschaft.org/zzub/browser/trunk/src/libzzub/driver.cpp
> for accessing the sound card. Libzzub, in turn uses rtaudio
> version 3.03, which is part of the libzzub source tree.
> The problem arises when I am running a jack server using my
> sblive, but specifying the default interface (hw:0).
> On startup, a vast number of xruns are generated (>200) and jack
> either falls over, or the computer almost completely locks up.
> This appears to be caused by rtaudio probing the alsa devices
> whilst jack is running. Interestingly, if I specify a sub-device
> (hw:0,3), or the integrated sound card (intel), no xruns are
> generated.
> I am wondering if this problem is arising because of a bug in the
> emu10k1 driver, or a problem with the way rtaudio probes alsa
> devices, or because it is a bad idea to probe alsa devices while
> they are being used by jack???

It's hard to tell.  In some cases, it's rahter a hardware setup
(e.g. assining another PCI slot helps) and in some cases it's a
software problem. 

It's possible that concurrent access to hw:0,0 may hold long locks.
Speciying hw:0,3 means that you're using another PCM device (the
multi-channel PCM), so the lock is likely specific to the PCM stream.
One difference between HD-audio and emu10k1 here is that emu10k1 has
multiple (sub)streams while HD-audio has a single stream.  Thus,
opening the same device will result in a blocking on HD-audio while
emu10k1 gives the next available substream.


More information about the Alsa-devel mailing list