Re: [Musicpd-dev-team] DSD over USB
Max, Sorry I've been on a holiday and totally missed out on anything digital. Although I didn't finish my implementation, I see you picked up the DSD development yourself which I'm happy about. You probably don't care, and probably too late.. but I do not agree with the addition of the added DSD sample type. I've attached my patch to give you an idea where I was heading to with the added FRAME_TYPE which in my opinion is the cleanest. Cheers mpd_dsd.patch Description: Binary data -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH 0/5] Add new decoder for outputting DSD data to 'DSD-over-USB' spec. - info
Hi Max and all,
I would like to help on the DSD MPD implementation as well.
- add a new audio format for DSD samples
I would like to propose the following changes/additions to audio_format.h:
enum frame_type {
FRAME_TYPE_UNDEFINED = 0,
FRAME_TYPE_PCM = 1,
FRAME_TYPE_DSD = 2,
};
Add uint8_t frame_type; to the audio_format struct.
Add a SAMPLE_FORMAT_U8 to the sample_format enum.
Max, is the addition of a frame_type to intrusive for you? ie. do you prefer to
specify something like SAMPLE_FORMAT_DSD_U8?
Cheers,
Bobby
--
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
Re: [Musicpd-dev-team] [PATCH 0/5] Add new decoder for outputting DSD data to 'DSD-over-USB' spec. - info
Ok, great, I prefer this as well. @Jurgen, @Jesus, I am willing to start the work for the first DSD patch is that alright with you guys? - 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 12:47 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 12:41, Bobby Beever bobby.bee...@yahoo.com wrote: Max, is the addition of a frame_type to intrusive for you? ie. do you prefer to specify something like SAMPLE_FORMAT_DSD_U8? No, I think that would be fine, even a good idea. It doesn't change the size of the audio_format struct (fills the remaining padding byte), and adds very little overhead, that could pay off when we add more frame types - such as Ogg frames for Ogg/Vorbis pass-through for radio streams. 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
Re: [Musicpd-dev-team] [PATCH 0/5] Add new decoder for outputting DSD data to 'DSD-over-USB' spec. - info
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
Re: [Musicpd-dev-team] [PATCH 0/5] Add new decoder for outputting DSD data to 'DSD-over-USB' spec. - info
I agree with you but I think it all has to do with the fact that the USB 2.0 Audio Class does not support native DSD and these vendors want DSD support in their hardware. It's may be shitty, but it is what it is.. Thank you for your suggestion, I'll make sure the plugin code remains as small as possible. -- 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
