Hmmm... I did some programming to test and verify this and the answer is:
Yes - in my setup you can by software control - switch between I2S and SPDIF.
I also tested several other issues related to this and I managed to temporary introduce a I2S locking problem...
As this was a programming issue due to the test setup it only happened after initialization of the Sabre32 / Arduino and before the setup of I2S / SPDIF.
Can you have both I2S and SPDIF playing and select one or the other?
Also, regarding register 14, Source of DAC 8,7,4 3 Does it mean I can "save" 4 or the 8 data inputs by taking the inputs from DAC 6, 5, 2 and 1?. Then I can use those inputs for spdif?
...Thanks.
Last edited:
yes that is the question, not that you cannot select them, you can indeed select them, but if you have something playing on both of them, at least in my experience the i2s will always be playing underneath. have you had the same issue glt??
because there is an SPDIF MUX, but there is only 1 I2s BUS that I guess underpins spdif
Last edited:
Well, I'm using Buffalo II where the spdif input is wired to DATA1 and LRCK of I2S is also connected to DATA1 (per datasheet) so if spdif and I2S are playing, there will be a conflict.
Since all 8 channels of I2S data only require 4 pins (DATA 2,3,4,5), then if one puts spdif in pins 6,7 or 8 there will not be any conflict. RayCtech's DAC seems to be configure in such way. So if I play I2S and select SPDIF in say pin DATA 8, then in theory pins DATA 1-DATA7 can be ignored
So in short, I can't test my hypothesis in BuffII...
Since all 8 channels of I2S data only require 4 pins (DATA 2,3,4,5), then if one puts spdif in pins 6,7 or 8 there will not be any conflict. RayCtech's DAC seems to be configure in such way. So if I play I2S and select SPDIF in say pin DATA 8, then in theory pins DATA 1-DATA7 can be ignored
So in short, I can't test my hypothesis in BuffII...
thanks, I have some new toys i'll be building up/populating over the next week or so that will facilitate testing this out easily. I havent set up the terminal connection to the ackodac MCU yet and dont have any arduino shield, so havent had direct access to the registers as such, but will be setting all of that up in the coming weeks (not auduino, the terminal and iphone/ipad control), have been a bit idle with my testing with the sabre of late as have been waiting for this to show up 
got here Xmas eve, so all the things i've been planning to do I can do without thinking I would be redoing them all over. need to test out the iphone/ipad software too, not sure how far along they are with the apps. already posted this over in the D1 thread, but thought it might be of interest here and I think its pretty we'll see if PTFE provides any audible benefits; also from these hirose mini BNC headers for the 2s signal integrity, i'm sure there will be some measurable with the XO paths in particular. TBH I dont care if it sounds the same as the standard ackodac, which was already excellent, the subjective/psychological benefits are bound to be huge
BTW the cables are not hooked up to anything, so connections are meaningless, was just taken for my mate
got here Xmas eve, so all the things i've been planning to do I can do without thinking I would be redoing them all over. need to test out the iphone/ipad software too, not sure how far along they are with the apps. already posted this over in the D1 thread, but thought it might be of interest here and I think its pretty
we'll see if PTFE provides any audible benefits; also from these hirose mini BNC headers for the 2s signal integrity, i'm sure there will be some measurable with the XO paths in particular. TBH I dont care if it sounds the same as the standard ackodac, which was already excellent, the subjective/psychological benefits are bound to be huge BTW the cables are not hooked up to anything, so connections are meaningless, was just taken for my mate
Attachments
Last edited:
To tell the truth, Chiaki's SDTrans192 for all revisions including the latest Rev. 3.0 encounters the same issue. That's why I posted my original question on a DPLL bandwidth parameter setting.
Using both Buffalo II and ESS ES9018 Evaluation board with 96MHz oscillators, I tried various parameter settings. The use of Sabre32 GUI software much helped me.
The only work-around that I have come to is "skipping OSF". Even on this setting, the recent SDTrans192 Rev. 3.0 can maintain a certain level of sound quality of a stable lock with "the lowest" DPLL bandwidth parameter for sources ranging from 44.1 kHz/16 bit to 352.8 kHz/24 bit.
People may, of course, think "skipping OSF" will bring a severe degradation.
However, I'd like to recommend that you once try the work-around.
The positive effect of "the lowest" setting may compensate the negative effect of non-oversampling.
There is a very good reason for the way the Buf II inputs are configured. It allows you to do stereo SPDIF/DSD/and I2S without having to reconfigure anything at all (except the SPDIF switch if it is not TTL) , not even firmware.
We could have skipped easy DSD support, but since we already have a great MUX there was really no need. Also I am glad we did not because the DAC does wonderfully with DSD input.
SPDIF multiplexing is still really simple with the BUF II, it is just external in our case. This is likely the best solution in any case since then you only need one comparator for SPDIF, and not one for each input. This cuts out a lot of unnecessary (for most) stuff and adds isolation between both the source and the MUX. Since we have the "MUX" there was no good reason to multiplex at the DAC itself.
I am also working on a pretty cool little I2S/DSD MUX and isolator at the same time I finish up the new USB module.
Cheers!
Russ
Last edited:
There is a very good reason for the way the Buf II inputs are configured. It allows you to do stereo SPDIF/DSD/and I2S without having to reconfigure anything at all (except the SPDIF switch if it is not TTL) , not even firmware.
We could have skipped easy DSD support, but since we already have a great MUX there was really no need. Also I am glad we did not because the DAC does wonderfully with DSD input.
SPDIF multiplexing is still really simple with the BUF II, it is just external in our case. This is likely the best solution in any case since then you only need one comparator for SPDIF, and not one for each input. This cuts out a lot of unnecessary (for most) stuff and adds isolation between both the source and the MUX. Since we have the "MUX" there was no good reason to multiplex at the DAC itself.
I am also working on a pretty cool little I2S/DSD MUX and isolator at the same time I finish up the new USB module.
Cheers!
Russ
What about those that need to connect both I2S and SPDIF sources?
How to switch between?
As for the SPDIF inputs I connect the optical receivers directly to the SPDIF mux, and for wired SPDIF inputs I use a pulse transformer and a true balanced to TTL one chip solution.
There are a couple solutions I can think of, but the simplest is just to convert the SPDIF to I2S.
My understanding of I2S with the Sabre32 are that you must select 32bit by the firmware to be able to receive 32bit data.
If you select 16bit or 24bit the Sabre32 uses the 16 or 24 MSB bits from the incoming data and then creates the remaining LSB bits up to 32bit by itself.
If you have selected 32bit the Sabre32 will for a 16bit source use the 16 data bits and then clock in the remaining "dummy" bits due to the 64FS clocking and use them as data.
What the "dummy" bits consist of you have no control over...
As I see this there are three options:
1. The firmware selects 32bit and you can receive true 32bit data and you get unknown LSB bits as data when the source are 16 or 24bits.
2. The firmware selects 16/24/32bit data either manually by user control or automatically by checking the incoming data for the bit depth and automatically selecting the correct bit depth.
3. Have a source / front end that always sends correct 32bit data - The SDTrans 192 unit are the only source known to me that are optimized for correct 32bit data transfere.
I do not know how the Buffalo II handles the incoming bit depth, but to actually be able to use real 32bit data the settings must be correct.
If you select 16bit or 24bit the Sabre32 uses the 16 or 24 MSB bits from the incoming data and then creates the remaining LSB bits up to 32bit by itself.
If you have selected 32bit the Sabre32 will for a 16bit source use the 16 data bits and then clock in the remaining "dummy" bits due to the 64FS clocking and use them as data.
What the "dummy" bits consist of you have no control over...
As I see this there are three options:
1. The firmware selects 32bit and you can receive true 32bit data and you get unknown LSB bits as data when the source are 16 or 24bits.
2. The firmware selects 16/24/32bit data either manually by user control or automatically by checking the incoming data for the bit depth and automatically selecting the correct bit depth.
3. Have a source / front end that always sends correct 32bit data - The SDTrans 192 unit are the only source known to me that are optimized for correct 32bit data transfere.
I do not know how the Buffalo II handles the incoming bit depth, but to actually be able to use real 32bit data the settings must be correct.
The Sabre32 PCB designed by "qusp" with the ES9018 can allow "whatever" firmware settings if configured accordingly, but NOT the Buffalo as the routing of the inputs forces some NOT selectable register settings to get ALL the internal DACs to work, and due to this several other register settings like inverting the phase are impossible or nearly impossible to implement for all quantizer modes etc..
This is not a critic of the Buffalo, just an explanation
This is not a critic of the Buffalo, just an explanation
Now I could be wrong, and I would invite Dustin to chip in. But my experience is that the bit depth setting seems to have no effect on I2S data. It does have a profound effect on the other PCM input types because for example RJ data the DAC need to from what point to justify.
My test was simple. Set the input mode to 16bit and I2S. Then create 32 bit sample and modulate the least significant 16bits only. Look at the results on the scope. You will see the modulation. At least I did when I tested it. Now I am prepared to concede I may have made a mistake, so I invite you to try the same thing and see if you get the same result.
My test was simple. Set the input mode to 16bit and I2S. Then create 32 bit sample and modulate the least significant 16bits only. Look at the results on the scope.
You will see the modulation. At least I did when I tested it. Now I am prepared to concede I may have made a mistake, so I invite you to try the same thing and see if you get the same result.