It's not really another format it's just a way to send DSD using an existing PCM link, imo this 'packing' code should really be in the output plugin as the DAC hardware manufactures come up with their own way to send DSD to their hardware. We currently have the dCS way of packing but there will be other ways of packing DSD into PCM in the near future as well, audio_format doesn't seem to be the right place to specify those. Looking at Steinbergs ASIO DSD implementation you basically see three DSD formats: 1-bit, 8-bit MSB and 8-bit LSB DSD. 1-bit is really inefficient and I don't see it ever being used, the others can be supported with what I proposed.
> The MPD core asks the output plugin to open with a certain audio... Thank you for that explanation! Now I understand it's push instead of request. I now also understand you prefer to have all the conversions take place within the convert filter, and to me the conversion from DSD to PCM for ex. is a perfect example that should take place in the convert filter. The packing (for me it's still not a real conversion only shifting some bytes around) is hardware vendor specific and imo should actually be in ALSA output plugin. The hardware vendors 'invented' this packing scheme as there is no official DSD support within Linux (ALSA), OS X, etc.. and currently the only official way to send DSD to a DAC is by using Windows ASIO.. I actually believe native DSD support within the OS will probably never happen. I propose we add user config support in the ALSA driver for these different DSD packing schemas, and now when I think about it, this setting could potentially damage ones speakers. So shouldn't the end-user should be responsible for telling MPD how their DAC wants native DSD packed? (it should convert to PCM by default). I hope I changed your mind.. Let me know what you think.. ----- Original Message ----- From: Max Kellermann <m...@duempel.org> To: Bobby Beever <bobby.bee...@yahoo.com> Cc: "musicpd-dev-team@lists.sourceforge.net" <musicpd-dev-team@lists.sourceforge.net> Sent: Saturday, February 4, 2012 2:02 PM Subject: Re: [Musicpd-dev-team] [PATCH 0/5] Add new decoder for outputting DSD data to 'DSD-over-USB' spec. - info On 2012/02/04 13:54, Bobby Beever <bobby.bee...@yahoo.com> wrote: > Shouldn't all the audio_output_plugins (maybe even filters) specify if they > are able to consume PCM and or DSD? IMO. the DSD inside PCM packing should > take place in the output plugin not somewhere else.. I thought it is another format, just like SAMPLE_FORMAT_S24 and SAMPLE_FORMAT_S24_P32 are distinct formats - even if it is just another representation of the same data. There is no need for output plugins to declare their compatibility. The MPD core asks the output plugin to open with a certain audio format; if the plugin does not support this format, then it will edit the audio_format for the next best one it understands. Then the MPD core will convert the data automatically (more specifically: it will ask convert_filter_plugin to do it). If it suports DSD-inside-PCM, and gets asked to use "true" DSD, it will just ask the MPD core to send DSD-inside-PCM instead. I'd like to make the plugins as simple as possible. Max ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
