[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 10/11] alsaaudio: change default playback settings
From: |
Christian Schoenebeck |
Subject: |
Re: [PATCH 10/11] alsaaudio: change default playback settings |
Date: |
Fri, 30 Dec 2022 15:05:40 +0100 |
On Friday, December 30, 2022 10:01:47 AM CET Volker Rümelin wrote:
> Am 28.12.22 um 14:52 schrieb Christian Schoenebeck:
> > On Monday, December 26, 2022 4:08:37 PM CET Volker Rümelin wrote:
> >> Am 21.12.22 um 12:03 schrieb Christian Schoenebeck:
> >>> On Sunday, December 18, 2022 6:15:38 PM CET Volker Rümelin wrote:
> >>>> The currently used default playback settings in the ALSA audio
> >>>> backend are a bit unfortunate. With a few emulated audio devices,
> >>>> audio playback does not work properly. Here is a short part of
> >>>> the debug log while audio is playing (elapsed time in seconds).
> >>> Which emulated devices are these?
> >> The hda device and sb16. When I wrote this patch two months ago ac97
> >> also had occasional dropouts, but at the moment ac97 works without issues.
> >>
> >>>> audio: Elapsed since last alsa run (running): 0.046244
> >>>> audio: Elapsed since last alsa run (running): 0.023137
> >>>> audio: Elapsed since last alsa run (running): 0.023170
> >>>> audio: Elapsed since last alsa run (running): 0.023650
> >>>> audio: Elapsed since last alsa run (running): 0.060802
> >>>> audio: Elapsed since last alsa run (running): 0.031931
> >>>>
> >>>> For some audio devices the time of more than 23ms between updates
> >>>> is too long.
> >>>>
> >>>> Set the period time to 5.8ms so that the maximum time between
> >>>> two updates typically does not exceed 11ms. This roughly matches
> >>>> the 10ms period time when doing playback with the audio timer.
> >>>> After this patch the debug log looks like this.
> >>> And what about dynamically adapting that value instead of reducing period
> >>> time
> >>> for everyone by default?
> >> It seems this would be only needed for the ALSA backend. All other
> >> backends with the exception of OSS are fine with a 10ms period, and the
> >> ALSA audio backend also uses 10ms with -audiodev
> >> alsa,out.try-poll=off,in.try-poll=off.
> > OK, but all it would need was adjusting dev->timer_period appropriately
> > either
> > in audio_validate_opts() [audio/audio.c, line 2126] to handle it generalized
> > or at the end of alsa_audio_init() [audio/alsaaudio.c, line 944] if
> > specifically for ALSA only, no?
>
> I think this should be the other way around. If period-length wasn't
> specified on the command line, it should be calculated from
> timer-period. With timer based playback or recording, the guest should
> be able to write or read new audio frames every timer-period
> microseconds. To have a high probability that the guest can write or
> read new frames every timer-period, the asynchronous updates of the
> audio backend have to be faster than timer-period e.g. 75-80% of
> timer-period. But that's a different patch.
Probably in both directions, depending on what the user supplied.
I still have this feeling that this patch might just move the problem to other
users (dropouts) until properly addressed, but anyway, for the time being:
Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> >>> 23ms is usually a good trade off between low latency, CPU load and
> >>> potential
> >>> for audio dropouts.
> >> Quite often it's longer than 23ms. For the rest of the audio backends a
> >> timer period of 10ms was selected as a good trade off between CPU load
> >> and audio dropouts. But you are right, this patch increases the CPU load.
> >>
> >> On my system the CPU load is increased by 0.9%. This was measured with a
> >> Linux guest using rhythmbox for audio playback. The guest was configured
> >> to use pulseaudio as sound server. The measurement was done with top -b
> >> -d 10 -n 14 over a period of two minutes. The first and last measurement
> >> was dropped. The average QEMU CPU load was 10.7% with and 9.8% without
> >> this patch.
> >>
> >> I would prefer a system with a 0.9% increased CPU load where audio just
> >> works over a system where you have to fine tune audio parameters.
> >>
- [PATCH 04/11] audio: remove unused #define AUDIO_STRINGIFY, (continued)
- [PATCH 04/11] audio: remove unused #define AUDIO_STRINGIFY, Volker Rümelin, 2022/12/18
- [PATCH 10/11] alsaaudio: change default playback settings, Volker Rümelin, 2022/12/18
- Re: [PATCH 10/11] alsaaudio: change default playback settings, Christian Schoenebeck, 2022/12/21
- Re: [PATCH 10/11] alsaaudio: change default playback settings, Volker Rümelin, 2022/12/26
- Re: [PATCH 10/11] alsaaudio: change default playback settings, Volker Rümelin, 2022/12/26
- Re: [PATCH 10/11] alsaaudio: change default playback settings, Christian Schoenebeck, 2022/12/28
- Re: [PATCH 10/11] alsaaudio: change default playback settings, Volker Rümelin, 2022/12/29
- Re: [PATCH 10/11] alsaaudio: change default playback settings, Volker Rümelin, 2022/12/30
- Re: [PATCH 10/11] alsaaudio: change default playback settings,
Christian Schoenebeck <=
[PATCH 09/11] audio: remove audio_calloc() function, Volker Rümelin, 2022/12/18