| Message ID | 8AEDA8BB-5138-47AF-98B7-D8E5BCE0E1FB@gmail.com |
|---|---|
| State | New |
| Headers | show |
On Tue, Sep 22, 2015 at 07:32:01PM -0400, Programmingkid wrote: > The USB audio card would not play audio well because its buffer was too small. > Increasing it made it play perfectly. All the crackling and dropouts are gone. > > Signed-off-by: John Arbuckle <programmingkidx@gmail.com> > > --- > This patch was tested on qemu-system-ppc running Linux and qemu-system-i386 > running Windows XP. Windows XP sound output thru the USB audio card sounded > perfect. Linux did improve in sound quality, but it still wasn't perfect. I > think there are problems with the hcd-ohci.c file. The Mac OS 10.2 guest in > qemu-system-ppc did not play sound due to USB issues unrelated to this patch. > > hw/usb/dev-audio.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c > index f092bb8..e4e4989 100644 > --- a/hw/usb/dev-audio.c > +++ b/hw/usb/dev-audio.c > @@ -88,6 +88,7 @@ static const USBDescStrings usb_audio_stringtable = { > #define USBAUDIO_PACKET_SIZE 192 > #define USBAUDIO_SAMPLE_RATE 48000 > #define USBAUDIO_PACKET_INTERVAL 1 > +#define BUFFER_MULTIPLIER 32 > > static const USBDescIface desc_iface[] = { > { > @@ -664,7 +665,7 @@ static const VMStateDescription vmstate_usb_audio = { > static Property usb_audio_properties[] = { > DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0), > DEFINE_PROP_UINT32("buffer", USBAudioState, buffer, > - 8 * USBAUDIO_PACKET_SIZE), > + BUFFER_MULTIPLIER * USBAUDIO_PACKET_SIZE), I'm not familiar with the code but I guess this also increases audio latency by a factor of 4 (8 -> 32). Gerd might have an opinion on whether that is okay or not. Stefan
On Oct 16, 2015, at 8:15 AM, Stefan Hajnoczi wrote: > On Tue, Sep 22, 2015 at 07:32:01PM -0400, Programmingkid wrote: >> The USB audio card would not play audio well because its buffer was too small. >> Increasing it made it play perfectly. All the crackling and dropouts are gone. >> >> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> >> >> --- >> This patch was tested on qemu-system-ppc running Linux and qemu-system-i386 >> running Windows XP. Windows XP sound output thru the USB audio card sounded >> perfect. Linux did improve in sound quality, but it still wasn't perfect. I >> think there are problems with the hcd-ohci.c file. The Mac OS 10.2 guest in >> qemu-system-ppc did not play sound due to USB issues unrelated to this patch. >> >> hw/usb/dev-audio.c | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c >> index f092bb8..e4e4989 100644 >> --- a/hw/usb/dev-audio.c >> +++ b/hw/usb/dev-audio.c >> @@ -88,6 +88,7 @@ static const USBDescStrings usb_audio_stringtable = { >> #define USBAUDIO_PACKET_SIZE 192 >> #define USBAUDIO_SAMPLE_RATE 48000 >> #define USBAUDIO_PACKET_INTERVAL 1 >> +#define BUFFER_MULTIPLIER 32 >> >> static const USBDescIface desc_iface[] = { >> { >> @@ -664,7 +665,7 @@ static const VMStateDescription vmstate_usb_audio = { >> static Property usb_audio_properties[] = { >> DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0), >> DEFINE_PROP_UINT32("buffer", USBAudioState, buffer, >> - 8 * USBAUDIO_PACKET_SIZE), >> + BUFFER_MULTIPLIER * USBAUDIO_PACKET_SIZE), > > I'm not familiar with the code but I guess this also increases audio > latency by a factor of 4 (8 -> 32). Didn't hear any problems. When I tried it out. > Gerd might have an opinion on whether that is okay or not. I doubt it. I don't even think he is with QEMU anymore. He doesn't even answer simple emails. He probably stopped working on QEMU. I do think it is time to add another USB maintainer.
On 16 October 2015 at 14:54, Programmingkid <programmingkidx@gmail.com> wrote: > > On Oct 16, 2015, at 8:15 AM, Stefan Hajnoczi wrote: >> Gerd might have an opinion on whether that is okay or not. > > I doubt it. I don't even think he is with QEMU anymore. He doesn't > even answer simple emails. He probably stopped working on > QEMU. I do think it is time to add another USB maintainer. A quick check shows that Gerd has been replying to emails on list this week; he hasn't gone anywhere... thanks -- PMM
On Oct 16, 2015, at 10:00 AM, Peter Maydell wrote: > On 16 October 2015 at 14:54, Programmingkid <programmingkidx@gmail.com> wrote: >> >> On Oct 16, 2015, at 8:15 AM, Stefan Hajnoczi wrote: >>> Gerd might have an opinion on whether that is okay or not. >> >> I doubt it. I don't even think he is with QEMU anymore. He doesn't >> even answer simple emails. He probably stopped working on >> QEMU. I do think it is time to add another USB maintainer. > > A quick check shows that Gerd has been replying to emails on list > this week; he hasn't gone anywhere... When I do send him emails, I use this address: kraxel@redhat.com. Is this the right address? Found it in the maintainers file. I sent him several USB based patches and he never responded. Am I doing something wrong or does he just not care anymore?
On Fri, Oct 16, 2015 at 09:54:12AM -0400, Programmingkid wrote: > > On Oct 16, 2015, at 8:15 AM, Stefan Hajnoczi wrote: > > > On Tue, Sep 22, 2015 at 07:32:01PM -0400, Programmingkid wrote: > >> The USB audio card would not play audio well because its buffer was too small. > >> Increasing it made it play perfectly. All the crackling and dropouts are gone. > >> > >> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> > >> > >> --- > >> This patch was tested on qemu-system-ppc running Linux and qemu-system-i386 > >> running Windows XP. Windows XP sound output thru the USB audio card sounded > >> perfect. Linux did improve in sound quality, but it still wasn't perfect. I > >> think there are problems with the hcd-ohci.c file. The Mac OS 10.2 guest in > >> qemu-system-ppc did not play sound due to USB issues unrelated to this patch. > >> > >> hw/usb/dev-audio.c | 3 ++- > >> 1 files changed, 2 insertions(+), 1 deletions(-) > >> > >> diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c > >> index f092bb8..e4e4989 100644 > >> --- a/hw/usb/dev-audio.c > >> +++ b/hw/usb/dev-audio.c > >> @@ -88,6 +88,7 @@ static const USBDescStrings usb_audio_stringtable = { > >> #define USBAUDIO_PACKET_SIZE 192 > >> #define USBAUDIO_SAMPLE_RATE 48000 > >> #define USBAUDIO_PACKET_INTERVAL 1 > >> +#define BUFFER_MULTIPLIER 32 > >> > >> static const USBDescIface desc_iface[] = { > >> { > >> @@ -664,7 +665,7 @@ static const VMStateDescription vmstate_usb_audio = { > >> static Property usb_audio_properties[] = { > >> DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0), > >> DEFINE_PROP_UINT32("buffer", USBAudioState, buffer, > >> - 8 * USBAUDIO_PACKET_SIZE), > >> + BUFFER_MULTIPLIER * USBAUDIO_PACKET_SIZE), > > > > I'm not familiar with the code but I guess this also increases audio > > latency by a factor of 4 (8 -> 32). > > Didn't hear any problems. When I tried it out. 8 buffers * 192 bytes / 3 byte (24-bit) mono samples = 512 samples 32 buffers * 192 bytes / 3 byte (24-bit) mono samples = 2048 samples At 48 kHz sample rate that is 10.6 milliseconds vs 42.6 milliseconds latency. I have never tried real-time audio processing under QEMU but when I use Linux for guitar effects it becomes noticable when latency is above around 12 milliseconds. ~5 milliseconds latency with USB audio is achievable on bare metal. So this change would make real-time audio feel laggy. Unless Gerd has a strong feeling that it's an improvement for QEMU, I wouldn't merge this change. Stefan
Hi, > So this change would make real-time audio feel laggy. That is secondary if the sound quality is bad due to constant overruns and underruns ... > Unless Gerd has a > strong feeling that it's an improvement for QEMU, I wouldn't merge this > change. The change is merged. cheers, Gerd
On Oct 26, 2015, at 7:00 AM, Stefan Hajnoczi wrote: > On Fri, Oct 16, 2015 at 09:54:12AM -0400, Programmingkid wrote: >> >> On Oct 16, 2015, at 8:15 AM, Stefan Hajnoczi wrote: >> >>> On Tue, Sep 22, 2015 at 07:32:01PM -0400, Programmingkid wrote: >>>> The USB audio card would not play audio well because its buffer was too small. >>>> Increasing it made it play perfectly. All the crackling and dropouts are gone. >>>> >>>> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> >>>> >>>> --- >>>> This patch was tested on qemu-system-ppc running Linux and qemu-system-i386 >>>> running Windows XP. Windows XP sound output thru the USB audio card sounded >>>> perfect. Linux did improve in sound quality, but it still wasn't perfect. I >>>> think there are problems with the hcd-ohci.c file. The Mac OS 10.2 guest in >>>> qemu-system-ppc did not play sound due to USB issues unrelated to this patch. >>>> >>>> hw/usb/dev-audio.c | 3 ++- >>>> 1 files changed, 2 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c >>>> index f092bb8..e4e4989 100644 >>>> --- a/hw/usb/dev-audio.c >>>> +++ b/hw/usb/dev-audio.c >>>> @@ -88,6 +88,7 @@ static const USBDescStrings usb_audio_stringtable = { >>>> #define USBAUDIO_PACKET_SIZE 192 >>>> #define USBAUDIO_SAMPLE_RATE 48000 >>>> #define USBAUDIO_PACKET_INTERVAL 1 >>>> +#define BUFFER_MULTIPLIER 32 >>>> >>>> static const USBDescIface desc_iface[] = { >>>> { >>>> @@ -664,7 +665,7 @@ static const VMStateDescription vmstate_usb_audio = { >>>> static Property usb_audio_properties[] = { >>>> DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0), >>>> DEFINE_PROP_UINT32("buffer", USBAudioState, buffer, >>>> - 8 * USBAUDIO_PACKET_SIZE), >>>> + BUFFER_MULTIPLIER * USBAUDIO_PACKET_SIZE), >>> >>> I'm not familiar with the code but I guess this also increases audio >>> latency by a factor of 4 (8 -> 32). >> >> Didn't hear any problems. When I tried it out. > > 8 buffers * 192 bytes / 3 byte (24-bit) mono samples = 512 samples > 32 buffers * 192 bytes / 3 byte (24-bit) mono samples = 2048 samples > > At 48 kHz sample rate that is 10.6 milliseconds vs 42.6 milliseconds > latency. > > I have never tried real-time audio processing under QEMU but when I use > Linux for guitar effects it becomes noticable when latency is above > around 12 milliseconds. ~5 milliseconds latency with USB audio is > achievable on bare metal. > > So this change would make real-time audio feel laggy. Unless Gerd has a > strong feeling that it's an improvement for QEMU, I wouldn't merge this > change. Have you done any testing using this patch yet? I have played several MP3 files and a video file. The audio plays very well. For the video file the audio was in-sync with the audio. I played a pinball game and the audio did match what was going on with the action of the game. With a powerful enough computer someone could play Guitar Hero in QEMU and not have any problems.
On Oct 26, 2015, at 8:24 AM, Gerd Hoffmann wrote: > Hi, > >> So this change would make real-time audio feel laggy. > > That is secondary if the sound quality is bad due to constant overruns > and underruns ... > >> Unless Gerd has a >> strong feeling that it's an improvement for QEMU, I wouldn't merge this >> change. > > The change is merged. > > cheers, > Gerd Thank you.
On Mon, Oct 26, 2015 at 01:24:00PM +0100, Gerd Hoffmann wrote: > > So this change would make real-time audio feel laggy. > > That is secondary if the sound quality is bad due to constant overruns > and underruns ... This is like sweeping network performance problems under the rug by increasing queue size. Before bumping the buffer size and breaking real-time applications (i.e. 128-512 samples per buffer), there should be a little performance investigation to understand the root cause. Why are overruns/underruns occurring? Is the problem the host sound API, QEMU's audio/mixing infrastructure, or guest responsiveness? Stefan
Hi, > Is the problem the host sound API, QEMU's audio/mixing infrastructure, > or guest responsiveness? Didn't check in deep this time, but usually none of the above. Latency problems *anywhere* in qemu can cause this, because the latency spikes cause the guest not being scheduled for too long so it can't fill the sound buffers in time. cheers, Gerd
On Oct 28, 2015, at 6:58 AM, Stefan Hajnoczi wrote: > On Mon, Oct 26, 2015 at 01:24:00PM +0100, Gerd Hoffmann wrote: >>> So this change would make real-time audio feel laggy. >> >> That is secondary if the sound quality is bad due to constant overruns >> and underruns ... > > This is like sweeping network performance problems under the rug by > increasing queue size. > > Before bumping the buffer size and breaking real-time applications (i.e. > 128-512 samples per buffer), there should be a little performance > investigation to understand the root cause. > > Why are overruns/underruns occurring? > > Is the problem the host sound API, QEMU's audio/mixing infrastructure, > or guest responsiveness? I think a better question is who is going to spend the time and energy trying to answer these questions? How about this, we apply the patch for now, and if someone does figures out a better way of solving this problem, we use the better way in the future.
On Wed, Oct 28, 2015 at 09:59:32AM -0400, Programmingkid wrote: > > On Oct 28, 2015, at 6:58 AM, Stefan Hajnoczi wrote: > > > On Mon, Oct 26, 2015 at 01:24:00PM +0100, Gerd Hoffmann wrote: > >>> So this change would make real-time audio feel laggy. > >> > >> That is secondary if the sound quality is bad due to constant overruns > >> and underruns ... > > > > This is like sweeping network performance problems under the rug by > > increasing queue size. > > > > Before bumping the buffer size and breaking real-time applications (i.e. > > 128-512 samples per buffer), there should be a little performance > > investigation to understand the root cause. > > > > Why are overruns/underruns occurring? > > > > Is the problem the host sound API, QEMU's audio/mixing infrastructure, > > or guest responsiveness? > > I think a better question is who is going to spend the time and energy > trying to answer these questions? To push patches like this is arrogant because your patch makes a trade-off: smooth playback on *your* system vs worse latency for *everyone*. You don't want to spend time understanding why playback is choppy on your system. That's fine. What bothers me is that you have no qualms about making latency on everyone's system worse. If you don't have time, that's fine. Just send an email to report the symptom and in the meantime use the qdev property to increase the buffer size for yourself: -device usb-audio,buffer=6144
On Oct 29, 2015, at 11:08 AM, Stefan Hajnoczi wrote: > On Wed, Oct 28, 2015 at 09:59:32AM -0400, Programmingkid wrote: >> >> On Oct 28, 2015, at 6:58 AM, Stefan Hajnoczi wrote: >> >>> On Mon, Oct 26, 2015 at 01:24:00PM +0100, Gerd Hoffmann wrote: >>>>> So this change would make real-time audio feel laggy. >>>> >>>> That is secondary if the sound quality is bad due to constant overruns >>>> and underruns ... >>> >>> This is like sweeping network performance problems under the rug by >>> increasing queue size. >>> >>> Before bumping the buffer size and breaking real-time applications (i.e. >>> 128-512 samples per buffer), there should be a little performance >>> investigation to understand the root cause. >>> >>> Why are overruns/underruns occurring? >>> >>> Is the problem the host sound API, QEMU's audio/mixing infrastructure, >>> or guest responsiveness? >> >> I think a better question is who is going to spend the time and energy >> trying to answer these questions? > > To push patches like this is arrogant because your patch makes a > trade-off: smooth playback on *your* system vs worse latency for > *everyone*. I'm sorry you are taking this so personally. I would never have submitted this patch if it causes a lot of problems to others. > You don't want to spend time understanding why playback is choppy on > your system. That's fine. I have been working on a sound output related problem for years. > What bothers me is that you have no qualms about making latency on > everyone's system worse. How do you know it makes sound on other people's systems worse? If you have actually done any testing, I would like to see the results. Here is a format I suggest you could use: Host operating system: Guest operating system: emulated machine: Tests conducted: video playback, game sound playback, ... > If you don't have time, that's fine. Just send an email to report the > symptom and in the meantime use the qdev property to increase the buffer > size for yourself: > > -device usb-audio,buffer=6144 The thing is I am certain is this patch makes sound play better. Before this patch the sound played back from the usb audio device was very poor. With this patch it sounds great. I have played video files in QEMU and if the latency was really high, then I would have noticed the audio not being in sync with the video. You have shown calculations, but you haven't given any real world examples of why this patch is bad.
Hi, [ context for spice folks: patch was added to qemu increasing usb-audio default buffer size ] > > What bothers me is that you have no qualms about making latency on > > everyone's system worse. > > How do you know it makes sound on other people's systems worse? If you have > actually done any testing, I would like to see the results. It's real. With that change we *do* actually trade latency for better sound quality. You probably wouldn't notice with pure music playback. Higher chance is with video playback. lip sync issues might show up, although you probably still have to watch carefully to actually notice. Anything sending audio both ways and expecting it to run with low latency (VoIP phone, music jam as mentioned by stefan) is affected even more. And we *do* actually just paper over the root cause. Problem is the real root cause can is very hard to track down. It can be pretty much anywhere in qemu, and even outside qemu. One known issue actually is in spice-server (added spice-devel because of that). It does audio processing in the qemu iothread (instead of a separate thread like it is done for the display channel). If you turn off audio compression in spice sound quality suddenly becomes better. I think this this happens because the latency spikes caused by audio compression go away. Happens with intel-hda and windows guests (which use very small audio buffers). Not (yet) investigated in detail though. cheers, Gerd
On Fri, Oct 30, 2015 at 11:59:29AM +0100, Gerd Hoffmann wrote: > > > What bothers me is that you have no qualms about making latency on > > > everyone's system worse. > > > > How do you know it makes sound on other people's systems worse? If you have > > actually done any testing, I would like to see the results. > > It's real. With that change we *do* actually trade latency for better > sound quality. > > You probably wouldn't notice with pure music playback. > > Higher chance is with video playback. lip sync issues might show up, > although you probably still have to watch carefully to actually notice. Regarding the video playback workload: video playback is not a low-latency audio use case. That's why you won't notice any difference if the USB audio device has a larger buffer size. Lip sync is about keeping the video frame and audio track timestamps within reasonable timing bounds. Video player application periodically checks the drift between the audio sample clock and the video clock. This can be implemented with large audio buffers, there is no need to sync every couple of milliseconds because the clock drift isn't that extreme. For examples of actual low-latency audio use cases, see: http://manual.ardour.org/synchronization/latency-and-latency-compensation/ Typically the application needs to process audio samples and play them back within ~10 milliseconds. An example is playing a software synthesizer. If the synthesizer application uses 40 millisecond buffers, then the piano will feel laggy because the user only hears the note after 40 milliseconds. Therefore, the low-latency audio use cases need small buffers to respond quickly enough. I downloaded Ubuntu Studio but haven't had time to try running it in a VM for testing yet: https://ubuntustudio.org/download/
Hi, > > Higher chance is with video playback. lip sync issues might show up, > > although you probably still have to watch carefully to actually notice. > > Regarding the video playback workload: video playback is not a > low-latency audio use case. That's why you won't notice any difference > if the USB audio device has a larger buffer size. Well, yes, it isn't low-latency indeed, but probably still sensitive to the buffer size. The buffer we are talking about here is a pure host-side thing, the guest doesn't know it exists and how big it is. > This can be implemented with large audio buffers, Yes, but for that the player needs to know how big the buffer is so the audio clock math is correct ... cheers, Gerd
diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c index f092bb8..e4e4989 100644 --- a/hw/usb/dev-audio.c +++ b/hw/usb/dev-audio.c @@ -88,6 +88,7 @@ static const USBDescStrings usb_audio_stringtable = { #define USBAUDIO_PACKET_SIZE 192 #define USBAUDIO_SAMPLE_RATE 48000 #define USBAUDIO_PACKET_INTERVAL 1 +#define BUFFER_MULTIPLIER 32 static const USBDescIface desc_iface[] = { { @@ -664,7 +665,7 @@ static const VMStateDescription vmstate_usb_audio = { static Property usb_audio_properties[] = { DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0), DEFINE_PROP_UINT32("buffer", USBAudioState, buffer, - 8 * USBAUDIO_PACKET_SIZE), + BUFFER_MULTIPLIER * USBAUDIO_PACKET_SIZE), DEFINE_PROP_END_OF_LIST(), };
The USB audio card would not play audio well because its buffer was too small. Increasing it made it play perfectly. All the crackling and dropouts are gone. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> --- This patch was tested on qemu-system-ppc running Linux and qemu-system-i386 running Windows XP. Windows XP sound output thru the USB audio card sounded perfect. Linux did improve in sound quality, but it still wasn't perfect. I think there are problems with the hcd-ohci.c file. The Mac OS 10.2 guest in qemu-system-ppc did not play sound due to USB issues unrelated to this patch. hw/usb/dev-audio.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)