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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
