You mean to upsample pcm to dsd256, or are you trying to do dsd512 from dsd256?
I noticed too that cpu load is 10-15% higher with this latest update, maybe your cpu worked on it's limit with previous OS builds already. Anyway I'm using the 2 PC setup and on server side on my old i5 750 cpu the upsampling of pcm to dsd256 still works ok (30% cpu load), but not dsd which works only with dsd64 to dsd128 upsampling.
I noticed too that cpu load is 10-15% higher with this latest update, maybe your cpu worked on it's limit with previous OS builds already. Anyway I'm using the 2 PC setup and on server side on my old i5 750 cpu the upsampling of pcm to dsd256 still works ok (30% cpu load), but not dsd which works only with dsd64 to dsd128 upsampling.
Try In Daphile the following path, in the add storage section:
nfs://192.168.1.10/volume1/MUSIC usage:music Identification: MUSIC
In my case (Synology NAS) named MUSIC, on which i have made a SHR (Synology Hybrid Raid) volume,
which is named "volume1"
On this volume there is a folder called MUSIC (and in this folder there are three sub folders:
"DSD" (for SACD.ISO and DSF files)
"PCM" for al pcm encoded music
"DXD" for the next generation DXD audio files
and in these folders are my music collections
SHR this is realy the best way to config your NAS, because now you can start with 3 harddisks, and expand over time extend the volume just by adding extra more harddisks! you cannot do did with RAID5 ;-)
Enable NFS sharing on you Synology NAS, don't forget to add your Daphile fixed ip adres to the NFS pool, so that Daphile is allowed to communicate with the NAS.
I also lowered my SMB protocol, to minimum (SMB1) other wise Ubuntu doesnt
want to connect with my NAS with Gb network connection....only 100 Mb speeds...
But this works in my case, i have now connection with my Daphile to my NAS over wired Cat6 cable, it took very long before my collection was imported....
nfs://192.168.1.10/volume1/MUSIC usage:music Identification: MUSIC
In my case (Synology NAS) named MUSIC, on which i have made a SHR (Synology Hybrid Raid) volume,
which is named "volume1"
On this volume there is a folder called MUSIC (and in this folder there are three sub folders:
"DSD" (for SACD.ISO and DSF files)
"PCM" for al pcm encoded music
"DXD" for the next generation DXD audio files
and in these folders are my music collections
SHR this is realy the best way to config your NAS, because now you can start with 3 harddisks, and expand over time extend the volume just by adding extra more harddisks! you cannot do did with RAID5 ;-)
Enable NFS sharing on you Synology NAS, don't forget to add your Daphile fixed ip adres to the NFS pool, so that Daphile is allowed to communicate with the NAS.
I also lowered my SMB protocol, to minimum (SMB1) other wise Ubuntu doesnt
want to connect with my NAS with Gb network connection....only 100 Mb speeds...
But this works in my case, i have now connection with my Daphile to my NAS over wired Cat6 cable, it took very long before my collection was imported....
Last edited:
So I'm back to Daphile after re-purposing a beefier PC I had. Any PCM resampling experts here? If I read the logs correctly Daphile uses max reported USB audio device supported bit-depth for the output format of SoX conversion. I can see the logic but it appears that USB interfaces can report supported bit-depth in excess of the actual capabilities of the DAC itself, so the logic is flawed. The end result Daphile sends wider words than the DAC can deal with and they get truncated in the DAC causing all sorts of negatives.
My actual use case is a Metrum Acoustics Musette NOS DAC. It is based on 16-bit R2R modules and has an XMOS card that is seen as a 32-bit device in Daphile. The DAC modules support up to 384kHz sampling. I'm resampling to 176.4kHz in Daphile and logs indicate that SoX resamples to 176.4kHz/32-bit and apparently this is what gets sent to the DAC. I confirmed with the designer the DAC will not perform any dithering to 16-bit internally so 1/2 of the information in each sample is dropped on the floor, that can't be good. The post-resampling dithering needs to happen in Daphile/SoX and 16-bit samples must be sent to the DAC.
Same kind issue is very likely when using a USB to SPDIF DDC, as very likely the DDCs bit-depth capabilities will exceed that of the downstream DAC.
It would seem that, similarly to the max sampling frequency audio device setting, there need to be a setting that allows to limit the bit-depth as well. I can set the bit-depth in the JRiver MC however I like, but this feature seems to be missing from Daphile. Or is it?
My actual use case is a Metrum Acoustics Musette NOS DAC. It is based on 16-bit R2R modules and has an XMOS card that is seen as a 32-bit device in Daphile. The DAC modules support up to 384kHz sampling. I'm resampling to 176.4kHz in Daphile and logs indicate that SoX resamples to 176.4kHz/32-bit and apparently this is what gets sent to the DAC. I confirmed with the designer the DAC will not perform any dithering to 16-bit internally so 1/2 of the information in each sample is dropped on the floor, that can't be good. The post-resampling dithering needs to happen in Daphile/SoX and 16-bit samples must be sent to the DAC.
Same kind issue is very likely when using a USB to SPDIF DDC, as very likely the DDCs bit-depth capabilities will exceed that of the downstream DAC.
It would seem that, similarly to the max sampling frequency audio device setting, there need to be a setting that allows to limit the bit-depth as well. I can set the bit-depth in the JRiver MC however I like, but this feature seems to be missing from Daphile. Or is it?
The rate effect of sox uses float32/float64. Internally sox uses int32 for passing samples between input/ effects/output. The only difference would be decimating to int16 instead of int32 which is basically no difference.
You would save a bit of CPU if preparing USB frames with 16bit instead of 32bit samples though - the frames would be shorter. But CPU load difference would be dimiscule as int32 is a basic PC format, most hardware is optimized for that.
You would save a bit of CPU if preparing USB frames with 16bit instead of 32bit samples though - the frames would be shorter. But CPU load difference would be dimiscule as int32 is a basic PC format, most hardware is optimized for that.
Are you saying it is a non-issue? It is possible I'm missing something but I see this:
[Decode] -F flc-wav-daphile-* -m 5a-e1-0c-6b-1c-a7 -p daphile -f wav -
Clock: 23:33:18.665
Source: Proxied stream from Media Server
Input format: FLAC, 44.1kHz, 16bits
SoX effects: [gain -1]->[rate -vMn 176400]
Output format: WAV (S32LE), 176.4kHz, 32bits
Which I think tells me SoX will resample/interpolate/etc. and produce 32bit samples that are then get forwarded to my DAC, where they are truncated them to 16 bits prior to the actual D/A conversion. Am I wrong?
Yes, I suppose the inability to cause dithering to happen in Daphile/SoX is my real complaint here.
Hi,
as you said gvl Daphile detects the hardware capability of the USB receivership of your DAC. If the DAC manufacturer decides to use a custom chip with custom installation and driver although this means that bits will be truncated I think the fault lies with the DAC manufacturer. I have a DAC where the XMos chip is specified with 24 bits while the DAC itself (R2R) claims 20 bit. I have sent 32 LE data (which implies truncating) and I cannot say it sounds bad. My other DAC (DS) runs the XMos as a 32 bit device and has 32 bit capability, so no truncation. Schiit's Yggdrasil truncated (to 21 bits) in the past, so do the soekris dacs (to 25 or 27 bits).
You are right textbook says if going below 32 bits (from higher bit depth) you should dither. Of course a NOS dac cannot dither because it cannot use filters (I think Metrum does not even use an analog reconstruction filter).
I agree that even if the root cause of the problem lies with the implementation of the XMos chip in your dac it would be nice to have a dithering option in Daphile.
Last question I would have is, do you want Daphile to increase bit depth or not? Because you can choose to send the file native to the dac.
If you want to increase bit depth (and maybe oversample) and then feed this data to a NOS dac in order to make sure to have the control over which digital filters will be used than HQPlayer might be a solution (never used it myself). I upsample everything in Daphile to 96 kHz because then I do not hear any differences between different filter types (e. g. sharp vs. slow)
as you said gvl Daphile detects the hardware capability of the USB receivership of your DAC. If the DAC manufacturer decides to use a custom chip with custom installation and driver although this means that bits will be truncated I think the fault lies with the DAC manufacturer. I have a DAC where the XMos chip is specified with 24 bits while the DAC itself (R2R) claims 20 bit. I have sent 32 LE data (which implies truncating) and I cannot say it sounds bad. My other DAC (DS) runs the XMos as a 32 bit device and has 32 bit capability, so no truncation. Schiit's Yggdrasil truncated (to 21 bits) in the past, so do the soekris dacs (to 25 or 27 bits).
You are right textbook says if going below 32 bits (from higher bit depth) you should dither. Of course a NOS dac cannot dither because it cannot use filters (I think Metrum does not even use an analog reconstruction filter).
I agree that even if the root cause of the problem lies with the implementation of the XMos chip in your dac it would be nice to have a dithering option in Daphile.
Last question I would have is, do you want Daphile to increase bit depth or not? Because you can choose to send the file native to the dac.
If you want to increase bit depth (and maybe oversample) and then feed this data to a NOS dac in order to make sure to have the control over which digital filters will be used than HQPlayer might be a solution (never used it myself). I upsample everything in Daphile to 96 kHz because then I do not hear any differences between different filter types (e. g. sharp vs. slow)
There is probably more uses for dithering control than I can think of, hopefully there is an elegant solution to address them all generically without unnecessarily complicating the implementation and/or the settings screen. Say have a bit-depth setting which allows to choose between "Automatic", or forced to say 16, 20, 24, 32 bits. The "Automatic" setting should not alter the bit-depth, apart from 0-padding maybe, unless the bit-depth of the material exceeds that of the hardware in which case it should dither down (I suspect this is how Daphile works now). This likely can be made be independent from the sampling rate setting but I suppose will need to rely on SoX internally. I'm maybe oversimplifying the problem, but hopefully you get the idea.
Edit: or, perhaps even easier, have a field to optionally override the hardware-reported supported bit-depth, hopefully the existing code will just take that value into consideration when deciding on the format of audio to send to the device, passing appropriate flags to SoX resampling including, if not covering all dithering use cases it will at least help to prevent sample truncation in the DAC.
Edit: or, perhaps even easier, have a field to optionally override the hardware-reported supported bit-depth, hopefully the existing code will just take that value into consideration when deciding on the format of audio to send to the device, passing appropriate flags to SoX resampling including, if not covering all dithering use cases it will at least help to prevent sample truncation in the DAC.
Last edited:
Software does not have control over parameters supported by hardware.
Your USB soundcard supports formats listed in altsets in file /proc/asound/cardX/stream0 (X = the soundcard index listed in aplay -l), just check them out. My 2 cents your model supports only S32_LE samples. Of course they are truncated in the actual soundcard but that is nothing you could influence.
Then the conversions are:
int16 input -> int32 internal sox format -> float64 rate effect at very high quality (parameter -v) -> int32 internal sox format -> int32 driver -> usb frames with 32bit samples -> 16bit your DAC.
Sox dithers automatically when decimating from >16bit to 16bit, unless instructed to avoid dithering with -D param. It is not dithering in your chain since no conversion to 16bit happens.
Your USB soundcard supports formats listed in altsets in file /proc/asound/cardX/stream0 (X = the soundcard index listed in aplay -l), just check them out. My 2 cents your model supports only S32_LE samples. Of course they are truncated in the actual soundcard but that is nothing you could influence.
Then the conversions are:
int16 input -> int32 internal sox format -> float64 rate effect at very high quality (parameter -v) -> int32 internal sox format -> int32 driver -> usb frames with 32bit samples -> 16bit your DAC.
Sox dithers automatically when decimating from >16bit to 16bit, unless instructed to avoid dithering with -D param. It is not dithering in your chain since no conversion to 16bit happens.
Exactly. But dither needs to happen for the best SQ in my case as the physical D/A conversion is 16 bits only. It is not my fault that in an otherwise nice DAC the manufacturer decided to slap on a non-customized XMOS USB interface that doesn't accurately report downstream D/A device capabilities. The point being you cannot generally trust reported HW capabilities as manufacturers don't always program their USB chipsets appropriately. Yes I agree it is a DAC design flaw, but being able to correct it in Daphile by specifying desired output bit-depth would be an easy way out.
On Windows there is the XMOS driver that sits between the applications and hardware, it comes with a control panel where one can limit the supported bit-depth, so there is that workaround. On Linux I think what happens the kernel enumerates the USB bus and the reads the capabilities directly from the H/W, these values reflect what the USB chipset/itself itself supports not the necessarily the DAC itself.
Last edited:
But you cannot specify any output format different from formats accepted by your hardware. Look at that stream0 file listing the altsets (alternate settings) your USB device advertises = accepts.
You could deploy 16bit dither in your software chain and still feed 32bit samples to your DAC using a regular linux distribution, but I do not know if daphile being a fixed-options linux distro offers such configuration flexibility.
You could deploy 16bit dither in your software chain and still feed 32bit samples to your DAC using a regular linux distribution, but I do not know if daphile being a fixed-options linux distro offers such configuration flexibility.
Sure, it must be one of the formats supported. But say if it must be 24 bits you can send 16-bits in a 24-bit envelope padded with 0-s as there is no harm in truncating 0-s. I realize there are ways to accomplish it outside of Daphile, but it would be a useful feature if added to Daphile.
Just update the new beta firmware, now, I can upscale from DSD64 to DSD512 with i7 7700K without problem... It is around 77% CPU utilization.
SSD TRIM function
Hi!
I just upgraded my Daphile build with a big 2 TB SSD.
I was wondering how I could TRIM it and looked all over the forum but couldn't find anything.
I ended up emailing Daphile feedback and got the following answer from Kimmo:
Daphile supports TRIM by using "discard" mount option for both EXT3/4 and VFAT file systems.
The "discard" option is enabled by default if the harddrive supports TRIM.
I thought it would be good to share this info here as Kimmo probably gets a lot of emails...
The "discard" mount option is also known as "continuous trim" and looks to me like a good solution for an SSD with probably not much writing/deleting as it is a "library".
My specs:
Inter-Tech E-W60 (pico-PSU + connection removed)
Asrock J3160TM-ITX + 65 W power brick (DC mobo/passively cooled)
2 x 4 GB Kingston DDR3 RAM
Crucial MX300 2TB SSD
(no fans, no moving parts = completely quiet)
Total power consumption: 12.1 W (resample to 24/96 + power to DAC via USB)
Audioengine D1 USB DAC
Dragon X Touch 10 Android tablet --> auto start Firefox in kiosk mode
(removed/disabled all the Google-sh*t and use it only for Daphile control)
PS: I'm new here, if I posted this in the wrong section, let me know.
Cheers!
Hi!
I just upgraded my Daphile build with a big 2 TB SSD.
I was wondering how I could TRIM it and looked all over the forum but couldn't find anything.
I ended up emailing Daphile feedback and got the following answer from Kimmo:
Daphile supports TRIM by using "discard" mount option for both EXT3/4 and VFAT file systems.
The "discard" option is enabled by default if the harddrive supports TRIM.
I thought it would be good to share this info here as Kimmo probably gets a lot of emails...
The "discard" mount option is also known as "continuous trim" and looks to me like a good solution for an SSD with probably not much writing/deleting as it is a "library".
My specs:
Inter-Tech E-W60 (pico-PSU + connection removed)
Asrock J3160TM-ITX + 65 W power brick (DC mobo/passively cooled)
2 x 4 GB Kingston DDR3 RAM
Crucial MX300 2TB SSD
(no fans, no moving parts = completely quiet)
Total power consumption: 12.1 W (resample to 24/96 + power to DAC via USB)
Audioengine D1 USB DAC
Dragon X Touch 10 Android tablet --> auto start Firefox in kiosk mode
(removed/disabled all the Google-sh*t and use it only for Daphile control)
PS: I'm new here, if I posted this in the wrong section, let me know.
Cheers!
Has anyone successfully used Schiit Eitr with the latest Daphile iso or for that matter any version including beta? Daphile recognizes Eitr as player though...
Tried using Modi by itself via usb, works great. Then tried usb-->Eitr-->Modi, no sound. Not sure if any relevant settings in mixer for Eitr. If anyone can shed some light on this, thanks.
I don't see any mixer settings for the Eitr
Tried using Modi by itself via usb, works great. Then tried usb-->Eitr-->Modi, no sound. Not sure if any relevant settings in mixer for Eitr. If anyone can shed some light on this, thanks.
I don't see any mixer settings for the Eitr