Jump to content
IGNORED

No DSD256 on micro iDSD


Recommended Posts

I changed my nano iDSD to micro iDSD. I could use the nano in DS256 with HQPlayer and Audirvana (Mac OS X latest os), however I could not use the new micro this way, the maximum allowed DSD rate is DSD128. I have exactly the same settings I was using for the nano which worked perfectly in DSD256. I upgraded the firmware on the micro now it is the latest 5.2 is installed.

 

In the Audio/Midi app the maximum shown bitrate is 384 kHz.

I rebooted the system several times, connected/reconnected, switched on/off the DAC. Powered through micro iUSB 3, connection from the CPU is Wireworld USB 3 cable and a Kingrex dual head red cable from iUSB 3 to the DAC, it was the same setup for the nano iDSD.

 

Filtering Bitperfect, Power mode eco and the output is direct.

 

Any idea what to check?

Link to comment

From afar, everything seems in order but based on your report of the Mac settings, something seems to be different as the micro iDSD and nano iDSD are identical in terms of setup - so you are correct with this assumption.

 

Ultimately the DAC is client and the computer is host.

 

If you have an iPhono/iPad with USB>Lightning, you can try DSD256 and if that works on the micro iDSD, then you know 100% it is the computer settings. See if you can rule in/out.

 

You can also open a support ticket

 

AMR & iFi-Audio :: Support Ticket System

 

and even though it is less likely to be the micro iDSD, the techies can try to help with your Mac and HQ Player settings. Though as always, best to contact HQ Player directly and send screenshots to them.

Our PowerStation is here: click me!

 

Check out our Tidal MQA Set-up Guides below. 
Android (Renderer) Mobile
Desktop (Decoder) via USB
Desktop (Decoder) via SPDIF

Link to comment

Thx for your quick reply.

 

Unfortunately I can not try it at the moment with an iPhone or iPad.

 

However as I mentioned even in the Audio/Midi app it shows available sampling rates only up to 384 kHz, while the nano showed up to 768. So it probably means it is not the question of HQplayer or Audirvana settings.

 

 

 

 

 

 

From afar, everything seems in order but based on your report of the Mac settings, something seems to be different as the micro iDSD and nano iDSD are identical in terms of setup - so you are correct with this assumption.

 

Ultimately the DAC is client and the computer is host.

 

If you have an iPhono/iPad with USB>Lightning, you can try DSD256 and if that works on the micro iDSD, then you know 100% it is the computer settings. See if you can rule in/out.

 

You can also open a support ticket

 

AMR & iFi-Audio :: Support Ticket System

 

and even though it is less likely to be the micro iDSD, the techies can try to help with your Mac and HQ Player settings. Though as always, best to contact HQ Player directly and send screenshots to them.

Link to comment
Thx for your quick reply.

 

Unfortunately I can not try it at the moment with an iPhone or iPad.

 

However as I mentioned even in the Audio/Midi app it shows available sampling rates only up to 384 kHz, while the nano showed up to 768. So it probably means it is not the question of HQplayer or Audirvana settings.

 

That means the nano has the 5.2A DoP firmware variant. Does an equivalent version exist for the micro?

Link to comment
That means the nano has the 5.2A DoP firmware variant. Does an equivalent version exist for the micro?

 

To recap sub-version 5.2A:

This enables DSD256(DoP) operation, which requires 768kHz PCM at the USB interface level.

• Nano iDSD and micro iDAC2 CANNOT decode 768kHz at the DAC level, but they can all be programmed to receive 768kHz PCM at the USB interface level hence enable DSD256(DoP).

• With 5.2A, the user MUST make sure to manually alter the PCM audio settings correctly (especially Mac), otherwise there will be no audio output at all.

• In other words, when playing PCM files, the sample rate must NOT set to be higher than 384kHz. Only set the sampling rate to 768kHz when one wants to play DSD256(DoP).

• There is no need to use this firmware if one uses ‘native mode’ (not DoP) to play DSD or DSD files are not played at all.

 

 

Due to different clock arrangements iDSD micro and Retro Stereo 50 already support 768kHz PCM and DSD 512 as well as DoP DSD 256 with the stock firmware.

The iDSD nano and iDAC2 micro are limited to 384kHz PCM and DSD 256 and (due to the 384kHz limit) DoP DSD 128 using the stock firmware.

 

- the 'A' firmware version enables 768kHz PCM support on Xmos. However the DAC part is still limited at 384kHz and DSD 256, so this firmware iteration does not allow 768kHz or DSD 512 playback, but it enables DSD 256 via DoP.

 

- this feature is only for those who use software setups that do not support ASIO DSD (Mac, iOS, most Linux) and wish to enable DSD 256 playback.

 

Due to USB Audio Class and XMOS physical USB layer limitations it is not possible to create a firmware for iDSD micro and Retro Stereo 50 to enable DSD512 via DoP (we tried hard).

Our PowerStation is here: click me!

 

Check out our Tidal MQA Set-up Guides below. 
Android (Renderer) Mobile
Desktop (Decoder) via USB
Desktop (Decoder) via SPDIF

Link to comment
To recap sub-version 5.2A:

This enables DSD256(DoP) operation, which requires 768kHz PCM at the USB interface level.

• Nano iDSD and micro iDAC2 CANNOT decode 768kHz at the DAC level, but they can all be programmed to receive 768kHz PCM at the USB interface level hence enable DSD256(DoP).

• With 5.2A, the user MUST make sure to manually alter the PCM audio settings correctly (especially Mac), otherwise there will be no audio output at all.

• In other words, when playing PCM files, the sample rate must NOT set to be higher than 384kHz. Only set the sampling rate to 768kHz when one wants to play DSD256(DoP).

• There is no need to use this firmware if one uses ‘native mode’ (not DoP) to play DSD or DSD files are not played at all.

 

Due to different clock arrangements iDSD micro and Retro Stereo 50 already support 768kHz PCM and DSD 512 as well as DoP DSD 256 with the stock firmware.

 

Well, for some reason, the OP's system only allows 384 kHz with the micro. If it also uses DoP for DSD, this would be limited to DSD128.

 

The iDSD nano and iDAC2 micro are limited to 384kHz PCM and DSD 256 and (due to the 384kHz limit) DoP DSD 128 using the stock firmware.

 

- the 'A' firmware version enables 768kHz PCM support on Xmos. However the DAC part is still limited at 384kHz and DSD 256, so this firmware iteration does not allow 768kHz or DSD 512 playback, but it enables DSD 256 via DoP.

 

- this feature is only for those who use software setups that do not support ASIO DSD (Mac, iOS, most Linux) and wish to enable DSD 256 playback.

 

Due to USB Audio Class and XMOS physical USB layer limitations it is not possible to create a firmware for iDSD micro and Retro Stereo 50 to enable DSD512 via DoP (we tried hard).

 

Would packing 24 DSD bits per DoP word help? With the standard 24-bit DoP words (8-bit marker + 16 data bits), there are 8 wasted bits per word since the XMOS only supports 32-bit input.

Link to comment
To recap sub-version 5.2A:

This enables DSD256(DoP) operation, which requires 768kHz PCM at the USB interface level.

• Nano iDSD and micro iDAC2 CANNOT decode 768kHz at the DAC level, but they can all be programmed to receive 768kHz PCM at the USB interface level hence enable DSD256(DoP).

• With 5.2A, the user MUST make sure to manually alter the PCM audio settings correctly (especially Mac), otherwise there will be no audio output at all.

• In other words, when playing PCM files, the sample rate must NOT set to be higher than 384kHz. Only set the sampling rate to 768kHz when one wants to play DSD256(DoP).

• There is no need to use this firmware if one uses ‘native mode’ (not DoP) to play DSD or DSD files are not played at all.

 

 

Due to different clock arrangements iDSD micro and Retro Stereo 50 already support 768kHz PCM and DSD 512 as well as DoP DSD 256 with the stock firmware.

The iDSD nano and iDAC2 micro are limited to 384kHz PCM and DSD 256 and (due to the 384kHz limit) DoP DSD 128 using the stock firmware.

 

- the 'A' firmware version enables 768kHz PCM support on Xmos. However the DAC part is still limited at 384kHz and DSD 256, so this firmware iteration does not allow 768kHz or DSD 512 playback, but it enables DSD 256 via DoP.

 

- this feature is only for those who use software setups that do not support ASIO DSD (Mac, iOS, most Linux) and wish to enable DSD 256 playback.

 

Due to USB Audio Class and XMOS physical USB layer limitations it is not possible to create a firmware for iDSD micro and Retro Stereo 50 to enable DSD512 via DoP (we tried hard).

 

Yes, understood, I read this in the Limoncello 5.2 firmware read me text pdf.

Sometime when I used the nano at DSD256, and stopped using Audirvana and used core audio for ordinary web browser sound I had to change 768 kHz to lower at Audio/Midi as it remained in 768 kHz there was no sound at all.

 

My question is how that can help my case to get DSD256 on the micro iDSD to work? I understood DSD512 is not available on my Mac because of the DoP limitations, can live with it, but would be nice to get the DSD256 work.

 

Somehow.

 

And quick.

Link to comment
Well, for some reason, the OP's system only allows 384 kHz with the micro. If it also uses DoP for DSD, this would be limited to DSD128.

 

 

 

Would packing 24 DSD bits per DoP word help?

 

Please refer to the open DoP Standard here:

 

http://dsd-guide.com/sites/default/files/white-papers/DoP_openStandard_1v1.pdf

Our PowerStation is here: click me!

 

Check out our Tidal MQA Set-up Guides below. 
Android (Renderer) Mobile
Desktop (Decoder) via USB
Desktop (Decoder) via SPDIF

Link to comment
Yes, understood, I read this in the Limoncello 5.2 firmware read me text pdf.

My question is how that can help my case to get DSD256 on the micro iDSD to work?

 

The answer was to Mansr.

 

The micro iDSD supports 768kHz and DoP DSD256 on Mac. We leave the support department to work through with you via screenshots/setups etc. The computer is the host and the DAC is the client. In essence the iDSD is 'dumb' it just natively plays what it is given up to 768kHz and DSD512. All the 'flavours' of firmware are to tailor-to the host.

Our PowerStation is here: click me!

 

Check out our Tidal MQA Set-up Guides below. 
Android (Renderer) Mobile
Desktop (Decoder) via USB
Desktop (Decoder) via SPDIF

Link to comment
Yes, the spec says 16 DSD bits per PCM word. There's no reason it couldn't be extended to allow 32-bit PCM carrying 24 data bits instead of wasting 8 bits if this would bring down the bandwidth requirement sufficiently.

 

An industry standard, even an open one only works if EVERYONE works with it. Changing DSD packing to 24 Bit would have to be applied both by DAC makers AND software writers across a WIDE range of products.

 

It would also 'break' DoP support on many platforms that do not work at 32 Bit but only 24 Bit (e.g. SPDIF, MADI etc.).

 

If you would like to propose such an amendment to the DoP standard, we suggest you join the group issuing the standard and get them to include such an amendment. Asking us to do it makes little sense.

Our PowerStation is here: click me!

 

Check out our Tidal MQA Set-up Guides below. 
Android (Renderer) Mobile
Desktop (Decoder) via USB
Desktop (Decoder) via SPDIF

Link to comment
An industry standard, even an open one only works if EVERYONE works with it. Changing DSD packing to 24 Bit would have to be applied both by DAC makers AND software writers across a WIDE range of products.

 

It would also 'break' DoP support on many platforms that do not work at 32 Bit but only 24 Bit (e.g. SPDIF, MADI etc.).

 

If you would like to propose such an amendment to the DoP standard, we suggest you join the group issuing the standard and get them to include such an amendment. Asking us to do it makes little sense.

 

I'm not asking you to do anything. I merely wondered if it would allow sending DSD512 to an XMOS USB receiver. If the bandwidth is still too high, there's no point exploring that idea further anyway. If it does help, the DoP spec could (naturally with the involvement of the relevant parties) be amended with a 32-bit version, perhaps signalled by a new tag in the top bits. I am absolutely not suggesting breaking the existing DoP format in any way.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...