[Qemu-devel] Re: [PATCH] alsaaudio: increase default buffer sizes

[malc <av1474@comtv.ru>]

On Thu, 8 May 2008, Jan Kiszka wrote:

> malc wrote:
>> On Tue, 6 May 2008, Jan Kiszka wrote:
>>

[..snip..]

> And those suffer audibly if you increase QEMU_ALSA_DAC_BUFFER_SIZE?

The latency becomes noticable the audio should be okay.

>>
>>>>
>>>>>
>>>>>> 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:
>>
>> Being enabled? Did you mean being built in? And what do you mean by
>> mechanism, mechanism to do what exactly?
>
> Yes, I meant built-in.
>
>>
>>> $ 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.
>>
>> What is the question?
>
> Such kind of documentation is not for wimps. You know where to find and
> why to use it, but does the average user do?

Sorry, i still do not understand the actual question you are/were asking.

>> [..snip..]
>>
>>>
>>> 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.
>>
>> It doesn't with ALSA on this machine, and on the machine next to this
>> one, and on machine that lies on the floor. It boils down to how ALSA
>> was configured by distribution maintainers.
>
> Chances are generally higher that broken ALSA setups are reported and
> fixed than broken OSS emulations.

There's nothing broken about it. Enabling dmix, thus degarding quality
and speed, is not what some may elect to do.

-- 
mailto:av1474@comtv.ru