RE: [virtio-comment] virtio sound: add missing definitions for 12 and 24kHz sampling rates

["Pape, Andreas (ADITG/ESS3)" <apape@de.adit-jv.com>]

Hello Manos,

thanks for reply..

Table 56 in HDA spec indeed lacks of mentioning 12 and 24kHz

But referring to the protocol itself (3.3.41: Stream Descriptor format) 24kHz is mentioned there.
Both rates are fitting into the 'submultiple scheme'.

3.3.41: Stream Descriptor format
Sample Base Rate Divisor (DIV):
000 = Divide by 1 (48 kHz, 44.1 kHz)
001 = Divide by 2 (24 kHz, 22.05 kHz)
010 = Divide by 3 (16 kHz, 32 kHz)
011 = Divide by 4 (11.025 kHz)
100 = Divide by 5 (9.6 kHz)
101 = Divide by 6 (8 kHz)
110 = Divide by 7
111 = Divide by 8 (6 kHz

12kHz is not mentioned there, assume just due to being a real uncommon rate.
Looking at the Linux HDA driver, it seems to e.g. allow the 9600Hz from table 3.3.41 even if also not mentioned in the 'defined sample rates'.
https://elixir.bootlin.com/linux/v6.6.1/source/sound/hda/hdac_device.c#L723
I am definitely not deep inside the HDA spec, thus I may be wrong..

My idea is to just add the definitions for these sampling rates to virtio spec - if a virtio sound device does not support these it must not expose these rate-bits.
At least for 24kHz I see no incompatibility to HDA spec due at least explicit presence in the stream descriptor spec. 



Regards,
Andreas



-----Original Message-----
From: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> 
Sent: Sonntag, 12. November 2023 15:05
To: virtio-comment@lists.oasis-open.org; Pape, Andreas (ADITG/ESS3) <apape@de.adit-jv.com>
Subject: Re: [virtio-comment] virtio sound: add missing definitions for 12 and 24kHz sampling rates

Hello Andreas,

The spec says it is purposely modeled to be compatible with the HDA spec. HDA is optimized for specific multiples or submultiples of 44.1 kHz and 48 kHz. Specifically, look at "5.4 Handling Stream Independent Sample Rates" and "Table 56. Defined Sample Rates". My (unexperienced) understanding of the following statement is that using such rates with controller hardware that is made for HDA will result in timing issues:

> This implies that the controller and link must also provide for an 
> exact sample-rendering rate at the codec, in order to avoid any long 
> term drift between sample delivery and rendering and the subsequent 
> over(under)-run of codec buffers.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.intel.com_content_dam_www_public_us_en_documents_product-2Dspecifications_high-2Ddefinition-2Daudio-2Dspecification.pdf&d=DwIDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=aWTtojMtCV9SvyEwkpBNuTjVnzMm-Wc09ONKDmVeCUo&m=CtBubv-z_ULu6xZVz5SCQLq2Yq5K2BJxDSLfS2WOKFChZmVQvRY9sAce_EtwF4pO&s=71EiX-sTc9LQVBNxiyt6VLb1eJBxf54HWOFP3ihOPtk&e=

If that is the case, I think the best approach would be to specify a non-HDA mode of operation to support more sound hardware. The most straight-forward solution though is for you to resample the audio before and after it goes through virtio-sound.


Regards,

-- Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd