multi audio output thread is running 100% and audio playback not working

[korli]

this after 6501f16

[diegoroux]

This was caused by an unnecessary memset to 0x00, in get_description. Which caused this if to never enter

int32 channels = desc->output_channel_count + desc->input_channel_count;
if (desc->request_channel_count >= channels) {
   create_multi_channel_info(info, desc->channels);
}

and also wiped the allocated channels pointer.

[diegoroux]

Although, #3 may cause further problems. I'm still trying to fix it

[korli]

I looked a bit at how virtio-sound manages the buffers it received. And it seems it just pushes them to the audio backend, and notifies the virtio driver that they are processed. as the event API isn't implemented also, I don't know any mean to know when a buffer is played. The only workaround I see ATM is the wait for the next period in buffer_exchange() after acquire_sem() succeeded with something like:
snooze_until(stream->real_time + 1000000L / rate * FRAMES_PER_BUFFER, CLOCK_REALTIME);

I also noticed that the default audio frame rate selected by multi_audio is the highest aka 384khz, which means the default buffer size is really small. I used locally:
#define FRAMES_PER_BUFFER (1024 * 16)

[korli]

@diegoroux I tried your branch on 64-bit and Qemu 9.0.0, I get a 100% cpu output thread in media_addon_server. Audio is somewhat working crakky. Seems I can't reopen this issue.

@scottmc

[diegoroux]

Hi, @korli

What I've tried is lowering the output/input bit rate. VirtIO exposes very high bit rates. At our end I could try limiting the max bit rate we use?

QEMU’s VirtIO device publishes high bit rates, regardless of the host.

Or do you have any other ideas?

[korli]

The buffer size could be made dependent of the audio rate.

[diegoroux]

Thanks, I'll try that