Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
On 03/22/2013 03:27 AM, Andreas Koch wrote:
I wouldn't worry about DSD wide, because that is a dead format that I was involved in launching for professional recording applications more than 10 years ago. It never took off.
I just need it for my own purposes, but I can make custom stuff as necessary if there's no interest from others.
Right now I'm just hoping to see a well defined common sample formats defined for ALSA that can be utilized by drivers. DoP could be implemented inside the driver or at ALSA layer instead of applications doing it. Not that I would mind, but I would find it cleaner than the current approach... :)
Currently, ASIO is the only API to support DSD sample formats. I understand that Microsoft or Apple is a slow to turn giant, but I'd hope ALSA wouldn't be such. ;)
There are already those IEC958 and DD/dts things being used for movie playback, so this wouldn't be such a big difference afterall.
- Jussi
At Fri, 22 Mar 2013 12:15:16 +0200, Jussi Laako wrote:
On 03/22/2013 03:27 AM, Andreas Koch wrote:
I wouldn't worry about DSD wide, because that is a dead format that I was involved in launching for professional recording applications more than 10 years ago. It never took off.
I just need it for my own purposes, but I can make custom stuff as necessary if there's no interest from others.
Right now I'm just hoping to see a well defined common sample formats defined for ALSA that can be utilized by drivers. DoP could be implemented inside the driver or at ALSA layer instead of applications doing it. Not that I would mind, but I would find it cleaner than the current approach... :)
Currently, ASIO is the only API to support DSD sample formats. I understand that Microsoft or Apple is a slow to turn giant, but I'd hope ALSA wouldn't be such. ;)
As Daniel already mentioned, adding a format type is trivial. It needs to be patched in different layers, though. But, the action is easy.
More important question is how consistent the format is. If it's a device-specific closed format, it's not suitable as a standard format definition in the API level.
There are already those IEC958 and DD/dts things being used for movie playback, so this wouldn't be such a big difference afterall.
IEC958 itself is a well-defined format as a container. So we actually have no definition for DD/DTS in the ALSA API level at all.
Takashi
On 03/22/2013 12:23 PM, Takashi Iwai wrote:
More important question is how consistent the format is. If it's a device-specific closed format, it's not suitable as a standard format definition in the API level.
At least the ASIO way of two uint8_t based MSB/LSB formats is pretty much the standard common denominator. Rest of the possibly needed data arrangement can be handled by the driver.
For the DoP output it is already defined by Andreas: http://dsd-guide.com/dop-open-standard
Which corresponds to the uint8_t with oldest bit in MSB. I'm now doing the packing for both packing styles in the application before sending it through ALSA. However, it would be cleaner for application to send uint8_t packets and handle the packing at driver level. Those pieces of custom USB hardware that don't use DoP but send raw DSD stream usually use either uint8_t or uint32_t containers. So the uint8_t is the lowest common denominator. So we wouldn't need to worry about the byte order in addition to bit order...
- Jussi
participants (2)
-
Jussi Laako -
Takashi Iwai