This is from here.
"There is something I don’t understand about how the Sabre DAC handles the I2S data. There could also be more to the way SPDIF is handled that ESS is not saying. For now, SPDIF allows setting the DPLL bandwidth to “lowest” which is the default setting of the Buffalo II DAC."
He also states that the 'lowest' setting is different for SPDIF than it is for i2s, and details many problems that occur when connecting i2s to the SABRE DAC.
At least I'm not alone....
I'll have to order the firmware from Twisted Pear to try it out. I think a set of transporters might help as well, I was going to get one set for my SACD player anyway, so I'll give it a shot and report back when I try. I might try separating the power supply from the USB cable, but the Transporter feels like a cleaner, better possible solution.
I looked at the link, that is a bit pricey for what I would need it to do.
Thanks for your help,
Aaron.
BII-80 does not work well with 384/352K material. Needs a 100 MHz clock.
I've documented the behavior in my setup here: Musiland 03 I2S to Buffalo II DAC: Playing 352.8Khz Music H i F i D U I N O
Regarding 32-bit, Windows 7 only reports 24 bit capability in the sound control panel - I was wondering about that too.
Standard (at least older as I have not checked newer) Buffalo firmware and clocks below 90.3168MHz for 352.8k and 98.304Mhz for 384k are not optimal or functional. However the ES9018 chip can be programmed to work with 352.8k and 384k with a 80MHz clock..
For the 32bit issue- I expect that to be a Windows / Windows application related issue as Linux works as a charm for me with my 352.8k/32bit AIFF files.
For the 32bit issue- I expect that to be a Windows / Windows application related issue as Linux works as a charm for me with my 352.8k/32bit AIFF files.
Code:
usb-orion-ehci.0-1, high speed : USB Audio
Playback:
Status: Running
Interface = 2
Altset = 1
Packet Size = 1024
Momentary freq = 352800 Hz (0x2c.199a)
Feedback Format = 11.13
Packet Size = 0
Momentary freq = 352800 Hz (0x2c.199a)
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 5 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
I discovered that playing 24bit sources used much more CPU than playing 32bit sources and filed a "bug" report for MPD.
The result was that the used decoder library (will not be fixed and is not optimal for high-end use) used 2 times the CPU power to decode 24bit compared to 32bit and MPD used again extra CPU to convert the 24bit data to the 32bit data that is sent to the USB adapter.
I am now using a different library that have "normal" CPU usage also with 24bit files.
I run with a highly optimized / tweaked and patched linux 3.5.2 kernel and a optimized and tweaked MPD 0.18, and customized and tweaked firmware for ES9018, and all the hardware is optimized and tweaked - as this is needed for optimum performance.
What I do not understand is that someone can expect a "standard" Windows setup with a ES9018 based DAC with non-optimal firmware and hardware setup can perform optimally above 192k-24bit/32bit..
The result was that the used decoder library (will not be fixed and is not optimal for high-end use) used 2 times the CPU power to decode 24bit compared to 32bit and MPD used again extra CPU to convert the 24bit data to the 32bit data that is sent to the USB adapter.
I am now using a different library that have "normal" CPU usage also with 24bit files.
I run with a highly optimized / tweaked and patched linux 3.5.2 kernel and a optimized and tweaked MPD 0.18, and customized and tweaked firmware for ES9018, and all the hardware is optimized and tweaked - as this is needed for optimum performance.
What I do not understand is that someone can expect a "standard" Windows setup with a ES9018 based DAC with non-optimal firmware and hardware setup can perform optimally above 192k-24bit/32bit..
Last edited:
What should be taken into consideration is that if we are not able to attain a certain level of "plug and play" reliability with these file formats they will never be commercially viable to use for distribution of music.......
Hi Guys,
I think a few people missed the main point of what I wrote before:
I've attached a few screenshots to show that I'm not blowing smoke. The exaU2I worked perfectly fine with 32 bit files (no errors from J River) and also played 384kHz files with no noise, and no irregularities when paused. You can call it luck or whatever you like, but you cannot say the BII 80MHz doesn't support 384kHz. It does.
Parts of this could be that the exaU2I supports ASIO, and maybe it's just J River that has problems playing 32 bit files via WASAPI, but either way, it's an issue. If it says there's 32 bit support, I should not have to jump through hoops to get it to work.
It's also definitely not a Windows 7 issue. As I said before, the exaU2I played just fine on the exact same PC.
RayCtech:
I have run bit-perfect tests on everything up to 384k 24b and I can assure you that a "standard" windows setup works just fine. I even ran a test overnight at 24b/192k, and after 16 hours of running there wasn't a single bit error. Not one. That means a simple windows setup provides every bit the same level of fidelity as anything else out there. The jitter levels on most of the devices I've tested are also exceedingly low. Unless you have a system with a noise floor that exceeds -150dB, then you generally don't have anything to worry about with an ES9018 and a variety of USB to I2S converters.
Implying that you need a specific build of Linux and custom firmware to get good performance sounds like a bit of marketing hype to me
I will be trying an isolator as shown in the schematic provided with the Amanero datasheet, and I hope that solves the issue at 384kHz. I'm starting to think that the BII is happier using it's own digital supply voltage to supply the driver for the I2S inputs. The biggest difference between the Amanero and the exaU2I is the isolation and the fact that the BII powers the output stages of the isolator. Maybe it's just very very fussy about grounding and noise, and it's impossible to get good performance without proper isolation.
I'll try in the next few weeks and report back. Hopefully Amanero can comment on the lack of 32 bit support using the WASAPI output more in J River.
Cheers,
Owen
I think a few people missed the main point of what I wrote before:
I've attached a few screenshots to show that I'm not blowing smoke. The exaU2I worked perfectly fine with 32 bit files (no errors from J River) and also played 384kHz files with no noise, and no irregularities when paused. You can call it luck or whatever you like, but you cannot say the BII 80MHz doesn't support 384kHz. It does.
Parts of this could be that the exaU2I supports ASIO, and maybe it's just J River that has problems playing 32 bit files via WASAPI, but either way, it's an issue. If it says there's 32 bit support, I should not have to jump through hoops to get it to work.
It's also definitely not a Windows 7 issue. As I said before, the exaU2I played just fine on the exact same PC.
RayCtech:
I have run bit-perfect tests on everything up to 384k 24b and I can assure you that a "standard" windows setup works just fine. I even ran a test overnight at 24b/192k, and after 16 hours of running there wasn't a single bit error. Not one. That means a simple windows setup provides every bit the same level of fidelity as anything else out there. The jitter levels on most of the devices I've tested are also exceedingly low. Unless you have a system with a noise floor that exceeds -150dB, then you generally don't have anything to worry about with an ES9018 and a variety of USB to I2S converters.
Implying that you need a specific build of Linux and custom firmware to get good performance sounds like a bit of marketing hype to me
I will be trying an isolator as shown in the schematic provided with the Amanero datasheet, and I hope that solves the issue at 384kHz. I'm starting to think that the BII is happier using it's own digital supply voltage to supply the driver for the I2S inputs. The biggest difference between the Amanero and the exaU2I is the isolation and the fact that the BII powers the output stages of the isolator. Maybe it's just very very fussy about grounding and noise, and it's impossible to get good performance without proper isolation.
I'll try in the next few weeks and report back. Hopefully Amanero can comment on the lack of 32 bit support using the WASAPI output more in J River.
Cheers,
Owen
Attachments
I havent connected the dac as yet but I just tried playing 384 @ 32bit and its certainly acting like its cool, 32bit is allowed to be selected and audio upsampled to 32/384 plays. this is in Lion in puremusic. will report back
yeah opc, soz I had to pop out, wanted to remind Ray that you had been able to perform the unendingly clever, exclusive and secret expensive miracles with other devices sample rates. ie. it played
it will sometimes do that, but officially the 80MHz XO isnt fast enough for 384 unless youve manually disabled the OSF in the ESS, so if its playing, its lying to itself =) you need >192*Fs for OSF ON, so lets say 256*Fs or 384kHz * 256 = 98.304MHz
edit: ahh but youre running async!!, so 80000kHz/384kHz = 208.3333 which is safely over the 192*Fs, soz I was thinking in whole multiples as ive been doing this math for sync mode lately.
yeah opc, soz I had to pop out, wanted to remind Ray that you had been able to perform the unendingly clever, exclusive and secret expensive miracles with other devices sample rates. ie. it played
it will sometimes do that, but officially the 80MHz XO isnt fast enough for 384 unless youve manually disabled the OSF in the ESS, so if its playing, its lying to itself =) you need >192*Fs for OSF ON, so lets say 256*Fs or 384kHz * 256 = 98.304MHz
edit: ahh but youre running async!!, so 80000kHz/384kHz = 208.3333 which is safely over the 192*Fs, soz I was thinking in whole multiples as ive been doing this math for sync mode lately.
Last edited:
opc mate, contact Ian hes made up some extra standalone boards for the isolator, he might be able to sort you out witrh a couple of PCBs
Last edited:
Report this as a bug and it is very likely that they will fix it relatively quickly. They seem pretty responsive to customer input which is one of the many reasons I like and use J River.
That's a good question... it could be a limitation of WASAPI or the way Windows reports sound card support.
One of the many reasons I prefer ASIO. It works in all versions of windows, and seems to be the most stable implementation I've used so far in terms of getting true bit perfect reproduction.
I'm secretly hoping Amanero will consider adding ASIO support under Win 7 32/64.
I'll give it a try using Foobar just to confirm, and then I'll submit a bug to j River and see what happens.
Cheers,
Owen