On Mon, Dec 22, 2008 at 04:22:42PM +0100, Pierre Riteau wrote:
> Hi,
> I noticed that when running `aucat -l', on some of my machines sndio
> apps would play the first sample buffer and then stop (for example,
> ogg123, but also sdlmame).
> These apps become unkillable by SIGTERM (they are killable by SIGKILL)
> until aucat is killed.
>
does "aucat -i file.wav" stop too while "aucat -l" is running?
> I found that running `aucat -l -m play` solves this issue, is it normal?
>
no, it shouldn't fail. The default server mode is full-duplex (and
it's supposed to work), so if there's a problem in the full-duplex
mode of the driver, using "-m play" might hide the problem.
you can test full-duplex mode as follows:
aucat -i file.wav -o /dev/null
it should play file.wav normally, does it? If it doesn't, could you
send me the stderr output when the above command is started with
AUCAT_DEBUG=4 env variable?
> It happens on VMware virtual machines but also on a real i386 with an
> auich sound chipset (unfortunatly I haven't had the chance to test the
> `-m play' workaround on it).
> Below is dmesg/audioctl/mixerctl of the VMware VM.
> I guess this is because my sound hw doesn't support fullduplex, as
> advertised in audioctl (why fullduplex and full_duplex anyway?) but
> shouldn't aucat work around this automatically? (I'm just playing sound,
> not recording at the same time).
>
If "aucat -l" is running in full duplex mode, then it will use
full-duplex even if sometimes all clients are only playing. That's
because it has to keep play and rec directions in sync, in case a
new client requests a full-duplex stream.
Anyway, if the driver advertises full-duplex, but actually it
doesn't support it, aucat can't guess it ;) and will fail.
-- Alexandre
