pippin wrote: > But how do you know which? I mean... if you resample to DSD you have to > know the output format, don't you? Is that normally DSF then?
You (the user) could choose. pippin wrote: > > But that's all PCM. > It assumes the DSD bitstream is already packaged as PCM and then selects > the applicable PCM format to open ALSA and send. It doesn't know > anything about DSD. > Yes, it is. DSD over PCM, native is a very inappropriate name, DOP is just a (special) case. pippin wrote: > > If I know all this I can probably do the same, but what I'd like to do > is to understand the stream and then either send it directly to USB or > resample to PCM if I have to use the built-in DAC (e.g. if headphones > are connected). So I need to understand I'm getting DSD and what format > it is in and all of that. Probably it's me, but seem s to me you are confusing the moments: 1. LMS (-> C-3PO) -> DSF || DFF -> Player You always know via slimproto what format you are receiving and here ends what LMS and C-3PO is concerned on. 2. Player -> (DOP || U32L || U32B || U24L || U24B || U16L || U16B) -> Device driver. Here you have to look to output_alsa.c, dsd.c and pcm.c to see how the device is opened, how is dsd data packed into pcm frames depending on the selected output format. pippin wrote: > > Here are my topics: > > > > - For the life of me I can't get my DSD DAC to recognize DSD input > when connected to any iThingy. Not with my App, not with Onkyo one > (which claims to be able to do this but is still an iOS 6 app). Not > with DoP, not with native. All of that works fine with the DAC > connected to a Raspberry Pi. - I'm especially concerned that not even DoP works. I mean... This > is being generated server-side and I don't touch it yet the DAC > interprets it as high-sample-rate PCM. No idea whether iOS touches > the data but I wouldn't know how and why. - What I want to do is be able to announce DSD as a player > capability and just send it to a USB device. - But if no USB device is connected (this can switch on the fly in > iOS, if you e.g. pull out the cable), I need to switch to PCM. I > could ever re-announce the player to the server without the DSD > capability but that would probably reset all the playback. If I > understand the whole thing I could just as well re-sample to PCM. > > > > > > I didn't find any code for this. Do you have a pointer? To me it looks > like it just sends the data it gets from the server to ALSA. > 1. call it as you want, but if the device (driver) do not announce itself as DOP (or dsd native) capable, there is no way to senf it DOP or DSD 'native' formats, is not going to work. 2. It's not a matter of iOs tuching the data, if the receiver do not investigates the marker, it will handle the stream as PCM. Notes that we have 2 versions of markers, maybe you should switch to the other one. 3. First part is simple, using slimproto. Second is not, you should know if the DAC (or his interface driver) is capable to detect DOP OR 'native' dsd and in witch format, then you have to pack data according to the selected format. 4. This is completely up to the player, I could foresee some problems and I thing at least you have to restart the track playback, if using slimproto. Real time switching to pcm during playback is hard, with DOP you maybe could, with other 'native' formats you sure have to close and reopen the device while keeping 'alive' the server connection. pippin wrote: > > So if it's not ready-made then you have to have implemented it yourself > :) So you should know what format you implemented, shouldn't you? Here is what I can't undrstand.. what are you thinking I don't know? If you ask 'why' they decide to use those formats, I don't know (but I suppose is becouse it's easier) if you ask how they are implemented, the answer is look at output_alsa.c, dsd.c and pcm.c in squeezelite-R2 repo or in Daphile patches. pippin wrote: > > Or did Kimmo do all this? Sure, as I already wrote ALL the DSD for ALSA stuff in Squeezelite-R2 comes from Daphile, SOX is from Måns Rullgard (https://github.com/mansr/sox), the little in C-3PO is mine. Some of Måns mods to sox was suggested by Kimmo, few where suggeste by me. Both Måns and Kimmo gave me precious help to understand things and let it work. but daphile's squeezelite version is different form mine and Ralphy's one, then it was not a matter to use something 'ready made' but to adapt what has been done by Kimmo to a different version. Same I suggest you to do. pippin wrote: > > I'll ask him, too, I have already implemented a ton of Daphile support, > this feature is actually supposed to go along with that. Great idea, Kimmo sure know more than me about, my intent is to provvide to all lms / squeezelite users in any platforms same great quality level provvided by Daphile, it happened that something I've found was usefull also for Daphile and Kimmo adopted it, but normally goes the other direction :-) p.s. Waht I've done has been communicated even to Ralphy in the hope is going to adopt it in the 'community' version. pippin wrote: > > Hm, so SqueezeLite gets the capabilities from the audio device? > Maybe I have to look closer at SqueezeLite but I didn't find any code > that re-packages DSD into PCM, I only found (3rd party) code that > re-samples DSD into PCM. Again, have look to output_alsa.c, pcm.c and dsd.c pippin wrote: > > Yes, I know, that's what I'd use, too, if I have to, it's an MIT license > so that works ("open source" might also mean GPL which would prevent it > from being usable on iOS, GPL forbids that). > > > pippin wrote: > > > > Where? That's what I'm asking for all the time, for the life of me I > > can't find it. > > There doesn't seem to be any specification of what format these "native" > > DSD streams are actually sent in to the DAC. Sorry, might just be just > > me being dumb but I don't find it. > > And I've asked on this forum half a dozen times in different places and > > didn't get a pointer as well.> > > > Again, have look to output_alsa.c, pcm.c and dsd.c for implementation > example, XMOS documentation repository / development platform, > steiberg ASIO documentation for more 'theoretical' explanation. > > > > pippin wrote: > > > > What they say is that they have MFI support. > > I do have the MFI specs but what that means is only that a vendor using > > their chipset can tell iOS what formats are supported and how they can > > do this. It doesn't say anything about how the actual formats work or > > how you select the correct mode on the DAC side. > > Maybe I have to ask them. > > > > > > No idea, this is all hidden from the application layer. They will surely > > have a driver (actually I could look that up in the MFI specs but it > > doesn't really help because it doesn't tell me what happens on the > > application side). > > I can only see "output routes" with certain capabilities and one of them > > indeed is raw USB audio output but if I use that I have to understand > > what to send. iOS doesn't know DSD or DoP so you have to do all that on > > top of the transparent raw data channel and you can't directly select a > > USB mode or send USB commands or something.> > > > Maybe XMOS development platform or documentation could help. ____________________________________________________________ SB+, Klimo Merlino + Kent Gold, Monitor Audio Studio 20 Gold SE+, Klimo reference and DIS Interconnect. ------------------------------------------------------------------------ marcoc1712's Profile: http://forums.slimdevices.com/member.php?userid=34842 View this thread: http://forums.slimdevices.com/showthread.php?t=106956
_______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
