[PleasantSounds]

Correct on the "padding".
 
Regarding what impact does it have on the DAC's working temperature, RF emissions or other side effects - I would expect that the 24-bit DACs do the "padding" internally on 16-bit streams just to have one uniform way of processing. So in the end exactly the same stream would be converted whether you send a 16-bit stream or padded to 24-bit.

 

[castleofargh]

Quote:
 

One more for the list; why is it that with WASAPI one has to select the Bit-depth? Again, I would expect Foobar to set the bit-depth based on the source...

ASIO does not have this option but I'm not quite happy with the sonic signature and prefer to use WASAPI.

it's an asio/wasapi thing. foobar does what most players would do. asio by default switches to the highest bitdepth it can detect(based on asio drivers provided for the device). it's the default action and the recommended action for asio, so there is little meaning in adding a bith depth setting when using asio.
now wasapi doesn't care and usually doesn't have device specific drivers. so it uses what you want it to use(if the DAC can handle it), so of course a bit depth setting makes sense.

 

[Traveller]

...so it uses what you want it to use(if the DAC can handle it), so of course a bit depth setting makes sense.

It makes sense to someone with a little more knowledge on the subject than me...

So what happens when a 24b96KHz source is fed via WASAPI set to 16bit? Do the additional 8 bits of data get dropped

 

 

[castleofargh]

 

...so it uses what you want it to use(if the DAC can handle it), so of course a bit depth setting makes sense.

It makes sense to someone with a little more knowledge on the subject than me...

So what happens when a 24b96KHz source is fed via WASAPI set to 16bit? Do the additional 8 bits of data get dropped

 

yes, that's why you have "dither" option for the 16bit setting(well you may have a use for dither for other reasons, but the obvious one is when the original file is 24bit played at 16).

 

[Soundsgoodtome]

His issue is there is no dither option on asio mode...is there?

yes, that's why you have "dither" option for the 16bit setting(well you may have a use for dither for other reasons, but the obvious one is when the original file is 24bit played at 16).

 

[Traveller]

Sigh... but that's my point re. WASAPI - why on Earth would anyone want to pipe their $$ 24-bit hi-res to their $$24-bit+ DACs using a 16-bit pipeline

But as recommended, I have set it to 24 bits and any 16-bit source data will simply be padded.

 

[castleofargh]

 wasapi is a simple more universal approach. you don't need to install specific wasapi drivers for every new DAC you get like for asio. if the you don't get custom asio drivers with your DAC, that's it. it's IMO the cool part of wasapi. but the consequence I guess is that wasapi doesn't have a custom made driver with all the information about the DAC. it's the same thing with direct sound in windows, you set the output yourself.
 
in general, if your DAC came with asio drivers(not the asio4all mess), and it works fine, I would suggest to use asio.

 

[514077]

   wasapi is a simple more universal approach. you don't need to install specific wasapi drivers for every new DAC you get like for asio. if the you don't get custom asio drivers with your DAC, that's it. it's IMO the cool part of wasapi. but the consequence I guess is that wasapi doesn't have a custom made driver with all the information about the DAC. it's the same thing with direct sound in windows, you set the output yourself.
 
in general, if your DAC came with asio drivers(not the asio4all mess), and it works fine, I would suggest to use asio.

I didn't realize ASIO4All was junk.  I'm using a Hugo.  If I removed A4All, would it remove asio use, or is the Chord driver enough?  Bare in mind, I'm still stuck with XP; can't afford a new machine yet.
Thanks for any advice you'd care to give.

 

[Soundsgoodtome]

  Sigh... but that's my point re. WASAPI - why on Earth would anyone want to pipe their $$ 24-bit hi-res to their $$24-bit+ DACs using a 16-bit pipeline

But as recommended, I have set it to 24 bits and any 16-bit source data will simply be padded.

You're saying WASAPI is a 16bit pipeline?

 

[castleofargh]

 
I didn't realize ASIO4All was junk.  I'm using a Hugo.  If I removed A4All, would it remove asio use, or is the Chord driver enough?  Bare in mind, I'm still stuck with XP; can't afford a new machine yet.
Thanks for any advice you'd care to give.

doesn't the hugo come with it's own asio driver? I thought it did.
asio4all as it's name implies is a tool that pretends to be asio when no proper asio driver are is provided for the DAC. but the actual system used I believe is kernel streaming(I'm not sure of that but I've read it somewhere). so if you already have actual asio drivers for the hugo, it would be meaningless to have asio4all. 

 

[castleofargh]

 

  Sigh... but that's my point re. WASAPI - why on Earth would anyone want to pipe their $$ 24-bit hi-res to their $$24-bit+ DACs using a 16-bit pipeline

But as recommended, I have set it to 24 bits and any 16-bit source data will simply be padded.

You're saying WASAPI is a 16bit pipeline?

if set to 16bit ^_^

 

[514077]

 

 
I didn't realize ASIO4All was junk.  I'm using a Hugo.  If I removed A4All, would it remove asio use, or is the Chord driver enough?  Bare in mind, I'm still stuck with XP; can't afford a new machine yet.
Thanks for any advice you'd care to give.

doesn't the hugo come with it's own asio driver? I thought it did.
asio4all as it's name implies is a tool that pretends to be asio when no proper asio driver are provided for the DAC. but the actual system used I believe is kernel streaming(I'm not sure of that but I've read it somewhere). so if you already have actual asio drivers for the hugo, it would be meaningless to have asio4all. 

It does.  Guess I'll dump A4A.  Thanks.

 

[PleasantSounds]

Originally Posted by castleofargh /img/forum/go_quote.gif
 
asio4all as it's name implies is a tool that pretends to be asio when no proper asio driver are is provided for the DAC. but the actual system used I believe is kernel streaming(I'm not sure of that but I've read it somewhere). so if you already have actual asio drivers for the hugo, it would be meaningless to have asio4all. 

 
That's correct: asio4all makes sense in the best case if your player does not support any bit perfect connections, but otherwise is just an unnecessary complexity and latency to deal with. Chord drivers support native ASIO so there's no need to use asio4all in that case.

 

[Traveller]

Next up... DSD playback

 
1. DSDIFF - "reports" sample rate (to external DAC) based on what you set its one & only parameter: "Max Sample Rate". Oddly, it defaults to 88200 (and max is 192000.)
In the end, I have no idea what Foobar is sending my DAC...

 
2. foo-input-SACD (ver 0.9.11) - obviously designed to do more than just DSD playback but it seems to play well with DSD. Aside from selecting either ASIO or WSAPI (event / push), the only parm (AFAIK) is its "output mode" (PCM or DSD, the latter being the obvious choice). I'm assuming it is a DoP based deal. It correctly "reports" the defined sample rates for both DSD128 & 256 (5.6MHz & 11.2MHz).
Oddly enough, the only issue I've come across is that it does not feed the Visualizations (Spectrum, etc.) when playing DSDs (PCMs are fine)... . Certainly not the worse issue and I prefer it over DSDIFF's poor "reporting"... .
 
I would be curious to know what you think (or know) to be the best DSD solution for Foobar. Important to me is that said solution does not degrade PCM playback in any way as my media in 99.5% PCM. Not that Foobar's Output-Selection feature could be any easier, but I would hope that at the end of this rainbow there is one perfect solution...

 

[castleofargh]

others will have to help here, I'm a total DSD hater so I never even tried to play any. sorry.