Re: [PATCH 1/2] ALSA: add DSD formats

[Jussi Laako <jussi@sonarnerd.net>]

On 04/06/2013 08:59 PM, Daniel Mack wrote:
> On 06.04.2013 19:53, Jussi Laako wrote:
>> On 04/06/2013 02:44 PM, Daniel Mack wrote:
>>> +#define SNDRV_PCM_FMTBIT_DSD_DOP_U8	_SNDRV_PCM_FMTBIT(DSD_DOP_U8)
>>> +#define SNDRV_PCM_FMTBIT_DSD_DOP_U16	_SNDRV_PCM_FMTBIT(DSD_DOP_U16)
>
> Well, the idea was to denote the fact that transport goes in multiple of
> 8 or 16 bits, which can then be interpreted by the calculation of the
> actual sample rate. But I'm fine with anything else. What name would you
> pick, assuming that you're fine with the general approach?

I would just leave out the DOP part and call it SNDRV_PCM_FMTBIT_DSD_U8 
(8 DSD samples per unit) and SDNRV_PCM_FMTBIT_DSD_U16 (16 DSD samples 
per unit). This way it is agnostic to the fact if driver actually 
implements DoP or something else when talking to the actual hardware. It 
assumes all the bits in the unit to be valid DSD samples without any DoP 
marker byte stuff. If driver implements DoP inside, it shouldn't be 
visible outside. If application implements DoP it will anyway pick a 
traditional PCM sample format for the purpose.

It could also  have SNDRV_PCM_FMTBIT_DSD_U32 which is suitable for 
PCI/PCIe and many USB cases. Helps on alignment requirements...

For example SNDRV_PCM_FMTBIT_DSD_U8 and ALSA sample rate of 352800 -> 
DSD sample rate of 2822400. Or SDNRV_PCM_FMTBIT_DSD_U16 and 176400 -> 
DSD sample rate of 2822400.


	- Jussi