malc wrote:
> On Mon, 5 May 2008, Jan Kiszka wrote:
> 
>> malc wrote:
>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>
>>>> Jan Kiszka wrote:
>>>>> malc wrote:
>>>>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>>>>
>>>
>>> [..snip..]
>>>
>>>>>
>>>>> Yeah, great, that was the key! Find below the version that works
>>>>> for me
>>>>> (on 64 bit 8) ). It even obsoletes my buffer size patch. Please merge!
>>>>
>>>> Declaring the buffer size tweak obsolete was too quick. I still need
>>>> more under certain guest load, but now I'm already fine with
>>>> DEFAULT_BUFFER_SIZE=4096. Or all in one:
>>>
>>> I wonder if everyone will be happy with quadrupled latency, apart from
>>
>> Hmm, I wonder about the scenario where this latency may actually hurt.
>> QEMU is not /that/ fast anyway. ;)
> 
> You would be surprised.

Tell me more! :->

> 
>>
>>> you and this other user on some (kvm was it) mailing list there are no
>>> huge outcries of dissatisfaction, then again i'm not sure how many
>>> people
>>> use ALSA+QEMU or QEMUs+AUDIO in general.
>>
>> I don't think many users are actually running QEMU (or KVM) against
>> ALSA. You have to
>> - manually enable it during configure
>> - pass QEMU_AUDIO_DRV=alsa (OSS remains default even if ALSA is on - I
>>   ran into this trap first.)
> 
> I don't see how it's a trap. You can also enable esd or fmod drivers
> in configure along with alsa, which one should be the default?

For sure, you need this mechanism with >1 audio backends being enabled
in parallel. It's just the question how one is supposed to find out
about this additional requirement:

$ grep -r QEMU_AUDIO_DRV qemu
qemu/audio/audio.c:        "  set QEMU_AUDIO_DRV=wav\n"
qemu/audio/audio.c:        "  export QEMU_AUDIO_DRV=wav\n"
qemu/audio/audio.c:        drvname = audio_get_conf_str ("QEMU_AUDIO_DRV", NULL, &def);

Am I missing some reference? Then sorry in advance.

> 
>> - possibly have to fix up your configuration with FIXED_FREQ and
>>   BUFFER_SIZE (as reported by >1 kvm users) until
>>
>> As OSS does not give us shared sound device access and, in the end, is a
>> deprecated API under Linux, my goal is to overcome remaining issues of
>> the ALSA support and then make /this/ the default one (under Linux).
>>
> 
> Huh? Even OSS/lite that is/was shipping with default Linux gave me
> "shared" sound, though i had a decent sound card with possibility to
> open the same /dev/dsp 16 times (it actually had 16 sigmatel chips on
> board). And the real OSS has vmix. And fwiw to have this wonderful
> "shared" sound you have to configure "dmix" (or whatever its called)
> too.

Well, probably configurable as well with compat-OSS (real OSS is dead on
Linux). The fact is that - not only for me - this sharing does not work
out-of-the-box with OSS, while it does with ALSA. Don't ask me why, I'm
not an expert on this, I'm rather looking at it from a "normal" user
perspective.

Jan