Re: [Musicpd-dev-team] [PATCH 0/5] Add new decoder for outputting DSD data to 'DSD-over-USB' spec. - info
On 2012/02/09 12:01, Bobby Beever bobby.bee...@yahoo.com wrote: What do you prefer and or propose? I don't understand the goal of this. First idea looks very dirty. DSD shouldn't be a special case, it's just yet another audio format. Replay gain cannot be applied because we don't have a software volume implementation for DSD. If you want bit-perfect playback, you don't want to enable replay gain or software volume. Since there is no DSD implementation, MPD will fail. As the dsd2pcm code needs to remain state I also propose to implement dsd2pcm into the convert_filter_plugin. Do you agree? Yes. And no. It doesn't belong in convert_filter_plugin, the call to dsd2pcm belongs in pcm_convert.c (and its neighbors). Mixers/Volume control.. I think we somehow need to be able to disable software (maybe also hardware) volume control. Would you agree? I currently have no proposal other than adding enable/disable state code to volume.c for a clean implementation. What are your thoughts on this? No, why would volume.c know or care about DSD? It never sees any actual audio data. You confuse me. Max -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ 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
On Sat, 2012-02-04 at 03:59 -0800, Bobby Beever wrote: 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? @Bobby, that's fine by me. If you lay down the ground work, I'll pitch in my part. Good to see this joint effort. Jurgen -- 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
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
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
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
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
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
Re: [Musicpd-dev-team] [PATCH 0/5] Add new decoder for outputting DSD data to 'DSD-over-USB' spec. - info
Bobby, I have no objection to you helping out:) Team, I have been developing a dsf to pcm converter that is similar to the current dff to pcm converter in place. However, my vote is that direct dsd support take priority. If the dsf to cpm code is needed for symmetry I'm happy to submit it to Max. I'm thinking it might be easier to develop the dcs/pcm plugins in tandem. Best Jesus R -- 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
[Musicpd-dev-team] [PATCH 0/5] Add new decoder for outputting DSD data to 'DSD-over-USB' spec. - info
Hi, I hereby sent a series of patches to add my new DSD decoder I talked about last December. The decoder supports outputting DSD data over PCM according to the proposed 'DSD-over-USB' standard by dCS. It reads raw DSD data from DFF (Philips) and DSF (Sony) formatted DSD files and sends the DSD data packed over PCM to a capable audio device like a DAC. Further features: - Packs DSD data into 24 or 32-bit PCM format - Seek support - Supports ID3 tags and tags native to DFF format Tested on 32-bit and 64-bit x86 and 32-bit ARM systems using a USB-to-spdif converter or firewire (snd-dice firewire sound driver). Patches are against current git. Some more info here: http://slimnet.home.xs4all.nl/mytek/ Jurgen -- 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
On 2012/02/03 16:17, Jurgen Kramer gtmkra...@xs4all.nl wrote: It output either 24 or 32-bit sample format packed in 32-bits. The 24-bit format could be removed as most newer devices support 32-bit sample formats. But these samples are *not* 24 or 32 bit. It is a strange protocol that abuses PCM samples to embed 1 bit samples. But there is no one-to-one relation between those faked PCM samples and the actual DSD samples. Therefore, you should not declare it as PCM. I think you misunderstand the DSD-over-PCM format. Why do you think so? You can absolutely can not do anything to the DSD data. It has to be sent bit perfect to the receiving device. Which is exactly my point. And it's why I don't like how you implemented the decoder, for the reasons stated in my previous mail. Your way of splitting patches is useless. Your last patch is the one that adds the new source files to the Makefile.am, which means none of the patches prior to that are useful - they don't add anything, except for source files that are not being used! Thanks, I am sorry but your manor of expressing yourself feels rather rude. I am just a hobbyist trying to create some useful code. Agree or disagree with criticism, but don't take it personal. I'm a hobbyist, too - MPD is my hobby. The patches are not meant be added individually, you would not have a working decoder. I split them as per request on the mpd patching guidelines so they easily viewed independently. Problem is, your patches cannot be viewed independently. Each of the patches depends on all of the others. None of this is incremental. An example of how I would write patches for the feature: - add a new audio format for DSD samples - implement conversion from DSD to PCM in the MPD's PCM conversion library, calling the dsd2pcm code that already exists - remove dsd2pcm calls from the existing dsdiff decoder plugin, pass DSD to decoder_data() - add new audio format for DSD inside PCM - implement conversion from DSD to this DSD inside PCM format - add support for DSD inside PCM to an output plugin - now's the time to add support for more tags or seeking to the dsdiff decoder plugin Each of the points above is an incremental patch that adds something useful. This works without duplicating code and without a second decoder plugin. It just works, even when you have multiple output plugins. Cross-fading and software volume won't work (unless you implement it in the PCM library), but at least it will not send broken noise to the output. 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
Max, this is the first attempt to get the code in for comments. I think it's understandable that some things may not be what you expect or require. I my fear has been that the longer the patch goes on without this kind of input the harder it would be to submit and have it excepted. Let us look into your comments Best Jesus R On Fri, Feb 3, 2012 at 9:49 AM, Max Kellermann m...@duempel.org wrote: On 2012/02/03 15:12, Jurgen Kramer gtmkra...@xs4all.nl wrote: Hi, I hereby sent a series of patches to add my new DSD decoder I talked about last December. The decoder supports outputting DSD data over PCM according to the proposed 'DSD-over-USB' standard by dCS. It reads raw DSD data from DFF (Philips) and DSF (Sony) formatted DSD files and sends the DSD data packed over PCM to a capable audio device like a DAC. Further features: - Packs DSD data into 24 or 32-bit PCM format - Seek support - Supports ID3 tags and tags native to DFF format Tested on 32-bit and 64-bit x86 and 32-bit ARM systems using a USB-to-spdif converter or firewire (snd-dice firewire sound driver). Patches are against current git. You made a few odd design choices which I don't agree with. Your code duplicates code from the existing decoder plugin. Not just that, it also adds new features to the forked version, which are not present in the other plugin. This is not acceptable for me. The plugin claims to write 24 or 32 bit samples, but in fact it does not. This will break many things, for example cross-fading, software volume, normalization, resampling, and breaks completely when you have multiple outputs one of which doesn't support this funny encoding that pretends to be PCM. A clean implementation would pass something like raw DSD data to the MPD core, and add code for conversion to the MPD's PCM library. That way, each output could declare if they want real PCM, or if they allow this encoded DSD data, or something else. Lines are too long (140 columns and more), and there are many stray whitespaces at line endings. Documentation in doc/user.xml is missing. Your way of splitting patches is useless. Your last patch is the one that adds the new source files to the Makefile.am, which means none of the patches prior to that are useful - they don't add anything, except for source files that are not being used! For example, your first patch adds a source file that #includes dsdnative/dsdnative.h, but that file does not exist yet - it will be added in the following patch. The macro CONF_DSDIFF_NATIVE isn't used. What is it supposed to be? The end result fails to compile: src/decoder/dsdiff_nativeplayback_plugin.c:182:2: error: 'input' undeclared (first use in this function) 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
