We have tried to change the connection from "SBC with USB and I2S -> USB cable -> USB to I2S XMOS card -> short internal cable -> DAC" to " SBC with USB and I2S -> short internal cable ->DAC". Theoretically the later, shorter solution should be better.
Actually the Cubietruck and Odroid C1+ were tried.
Cubietruck required a small hardware mod to enable stereo I2S, while C1+ started to work immediatelly. Now both of them operates flowlessly with RuneAudio software. Technically at least.
But the sound was quite dissapointing relative to the USB XMOS solution.
Using SBC I2S output with classical music, the piano sounded like hit by a rod, nothing natural was in it. Agressive, plus the mid range was rather missing. Similar result with both of the SBCs.
This can be caused by either a poorly implemented Unix I2S driver, or some hardware issue.
Thanks for any idea how to proceed.
Actually the Cubietruck and Odroid C1+ were tried.
Cubietruck required a small hardware mod to enable stereo I2S, while C1+ started to work immediatelly. Now both of them operates flowlessly with RuneAudio software. Technically at least.
But the sound was quite dissapointing relative to the USB XMOS solution.
Using SBC I2S output with classical music, the piano sounded like hit by a rod, nothing natural was in it. Agressive, plus the mid range was rather missing. Similar result with both of the SBCs.
This can be caused by either a poorly implemented Unix I2S driver, or some hardware issue.
Thanks for any idea how to proceed.
Well, the driver possibility is easily eliminated by simply taking the bitstream into another I2S port and making sure it decodes correctly (It almost certainally does), Linux audio drivers are not that prone to contain gratuitious 'enhancers' and the like.
The other, possibility is timing, MCLK usually being the critical one, and this can be rather poor on some board designs. How are you handling this signal (and its associated return path)?
Also for that matter, WHY should a shorter solution that is taking a critical clock from the motherboard be expected to be better then one generating the critical clock off the board? Simpler is NOT in general better (Neither is it automatically worse), and a USB peripheral handling all the audio clock generation and pulling the data from the computer as required is entirely believable being better then a afterthought design on a motherboard (They are not always better, but they can be).
I get rather fed up with this belief that a shorter 'signal path' (Awful phrase, ignores about half the action) is a better one, sometimes all that complexity serves a valid purpose.
Regards, Dan.
The other, possibility is timing, MCLK usually being the critical one, and this can be rather poor on some board designs. How are you handling this signal (and its associated return path)?
Also for that matter, WHY should a shorter solution that is taking a critical clock from the motherboard be expected to be better then one generating the critical clock off the board? Simpler is NOT in general better (Neither is it automatically worse), and a USB peripheral handling all the audio clock generation and pulling the data from the computer as required is entirely believable being better then a afterthought design on a motherboard (They are not always better, but they can be).
I get rather fed up with this belief that a shorter 'signal path' (Awful phrase, ignores about half the action) is a better one, sometimes all that complexity serves a valid purpose.
Regards, Dan.
Dan, thank you for your notes.
I agree that shorter path is not automatically better. Unfortunatelly here are two examples. Design and the parts counts a lot. But to dismiss the USB part of the chain seems to be a good idea, just because it is totally unnecessary. USB is widespread on computers, and till now the audio was suited to the computer industry. But now here is solution directly for audio applications. So the question is how to make it better?
The test was done at my electrical engineer audio buddy, he provides the technical part of the project. He has a ES9018S DAC with own master clock, so the MCLK on the SBC seems not critical.
He has an idea what to do, but i decided to ask the community if a ready solution or other ideas exist. Furthermore can anybody to suggest another SBC with better I2S results? Better than an isolated or nonisolated diyinhk XMOS or Amanero.
An Odroid XU4 board is already on the way to try (it has 1.8V I2S output only, but it can be shifted to 3.3V we need). I'm also thinking to get an Intel powered Minnowboard Turbot, maybe they provide a better I2S bus for audio than the ARM jungle.
I agree that shorter path is not automatically better. Unfortunatelly here are two examples. Design and the parts counts a lot. But to dismiss the USB part of the chain seems to be a good idea, just because it is totally unnecessary. USB is widespread on computers, and till now the audio was suited to the computer industry. But now here is solution directly for audio applications. So the question is how to make it better?
The test was done at my electrical engineer audio buddy, he provides the technical part of the project. He has a ES9018S DAC with own master clock, so the MCLK on the SBC seems not critical.
He has an idea what to do, but i decided to ask the community if a ready solution or other ideas exist. Furthermore can anybody to suggest another SBC with better I2S results? Better than an isolated or nonisolated diyinhk XMOS or Amanero.
An Odroid XU4 board is already on the way to try (it has 1.8V I2S output only, but it can be shifted to 3.3V we need). I'm also thinking to get an Intel powered Minnowboard Turbot, maybe they provide a better I2S bus for audio than the ARM jungle.
How are you phase locking the two master clocks?
Also, be aware that some motherboards only do 48KHz and multiples natively (Check the frequency of the LRCLK), if you are really running a 48K audio stream with a the DAC boards XO free running at a rate suited to 44.1 it will obviously sound awful (Same thin if the hardware only supports 48K and the driver is having to do a simple minded ASRC to get things to work).
Regards, Dan.
Also, be aware that some motherboards only do 48KHz and multiples natively (Check the frequency of the LRCLK), if you are really running a 48K audio stream with a the DAC boards XO free running at a rate suited to 44.1 it will obviously sound awful (Same thin if the hardware only supports 48K and the driver is having to do a simple minded ASRC to get things to work).
Regards, Dan.
The boards were tried "as is", without any meassuring or mods to get better results.
I think the boards have separate clock for 44.1x and 48x kind of source, but I'm not sure in it, it should be checked.
When the Odroid XU4 will arrive, we will go on to detect and fix the problem if my EE audio buddy can do it.
I think the boards have separate clock for 44.1x and 48x kind of source, but I'm not sure in it, it should be checked.
When the Odroid XU4 will arrive, we will go on to detect and fix the problem if my EE audio buddy can do it.
I was using the cm6631a from diyinhk, a lot of people say the xmos is better but really out of my price range and yes i am using the master clock of the odroid what i noticed at first was how quiet it is because i always had hash noise from the usb to i2s board even though i earthed properly but now silent.
Last edited:
i'm the opposite, i'm personally impressed with the SQ of such a little device that costs peanuts but i use RPi, iqaudio dac+ and MoOde fed to RJM's Sapphire head amp. the RPi and dac+ smash the SQ of my oppo bdp93.
i think you have to remember that these little card computers were not designed with audio in mind but to do other things such as robotics so asking them to do something they weren't designed too is asking for trouble. add in that its still in its infancy and i think the developers are doing a superb job. all audio hardware and software for these little things have been designed/written from the ground up. what impresses me the most is the speed at which development is progressing. if i'm not mistaken the RPi was the first of its kind and was launched in 2012 for public sale. yes that's only four years ago.
i think you have to remember that these little card computers were not designed with audio in mind but to do other things such as robotics so asking them to do something they weren't designed too is asking for trouble. add in that its still in its infancy and i think the developers are doing a superb job. all audio hardware and software for these little things have been designed/written from the ground up. what impresses me the most is the speed at which development is progressing. if i'm not mistaken the RPi was the first of its kind and was launched in 2012 for public sale. yes that's only four years ago.
Unfortunatelly never tried the CM6631A. I use diyinhk XMOS with Lampizator linear power supply. That's the converter we would like be beat with the direct I2S.
Probably next week the SBC's will also get linear PSU in the hope of some sonic improvement. The newly arrived XU4 already got the Ubuntu image + 1.8V->3.3V shifter. It works fine according to the instruments, but we can try it in the test system on the next week only.
Probably next week the SBC's will also get linear PSU in the hope of some sonic improvement. The newly arrived XU4 already got the Ubuntu image + 1.8V->3.3V shifter. It works fine according to the instruments, but we can try it in the test system on the next week only.
Not sure if your opinion is very different from mine.
Agreed, SBCs are not primarily audiofil products. I also think they are good enough for many music lovers as is.
But the I2S bus, relatively simple construction, small number of parts, and the low power consumption are the things may make SBCs a better transport, than my currently used MAC mini and the likes. Much easier to build a really good power supply for it. Need just a few component to add/replace for both the SBC and it's PSU, so you can select really good parts - Black Gates, Sinkoh tantals, Motorola Schottky etc., or others what you like -.
This idea is come from my audio buddy, and I was easily convinced it worth to try. I think there few are others with similar opinion. Maybe it will work, maybe not. The idea seems to be more realistic for me, than building "audiofil" grade Windows 2012 XEON servers and the likes.
A good audio transport is the first part of a three parts project.
The second part is a DAC board. It was already planned, components were purchased, but the PCB design is still missing.
The last part is the DAC's tube output stage is ready, and it plays music quite better than my Lampizator Amber DAC. I feel the Amber has a good tube output for the money, while my new gem is a different design, and contains very scarce, almost impossible to find components. Not adequate for mass production. But who cares?
I think the C1 to C1+ was specifically updated and designed with I2s output in mind and being only 5 volts its amazingly easy to power, the price was less than any of the Usb to I2s boards I have with more versatility. Diminishing returns starts to appear for me and implementation is important. Don't believe me when I say its good, one should find out for themselves. when I hear people talk about how good something is I get suspicious.
Last edited:
As far as I know, I2S bus is simply a part of the CPU design, and board makers can only decide they make it available for their users on a specific board or not. There are a range of ARM CPUs today providing this facility.
And yes, there are quite cheap and even cheaper boards. Good time for music lovers and for many others.
And yes, there are quite cheap and even cheaper boards. Good time for music lovers and for many others.
I mostly have 16bit 44khz audio which can sound as good as higher res, depending on original recordings to my ears, I mean I2s is not new its been round for so many years, these new devises are so advanced compared to the original ideas surrounding the I2s interface and so these mini computers are designed to accommodate Hi Def audio as well now being a PC format.
Last edited:
I know what you are speaking of. Very surprised, because it's a history today. The I2S was introduced by Philips a few decades ago. Philips also had a few very good ladder DACs in that time. I personally preferred the Philips CD-304 CD player, with the original TDA1541 14(!) bit ceramic based DAC chip, and CDM1 mechanics. It had an awful sound comparing to the vinil, but it was fantastic tweaking base to match the expectations.
Got tube a output with Bendix 6074 and 6900 tubes, Van den Hul MCS-1000 internal silver cable, Shinkoh tantals, Black gate caps, and a few other mods. Even the CDM1 (one of the very best CD mechanics ever made) was tuned. I still have the Philips, it is my first and possibly the last CD player.
Sorry if we are a bit off-topic here, most topic member probably doesn't know what we are speaking off.
I would like to do something similar now but with computer transport, using a 20 bit ladder DAC, and again a tube output stage.
Got tube a output with Bendix 6074 and 6900 tubes, Van den Hul MCS-1000 internal silver cable, Shinkoh tantals, Black gate caps, and a few other mods. Even the CDM1 (one of the very best CD mechanics ever made) was tuned. I still have the Philips, it is my first and possibly the last CD player.
Sorry if we are a bit off-topic here, most topic member probably doesn't know what we are speaking off.
I would like to do something similar now but with computer transport, using a 20 bit ladder DAC, and again a tube output stage.
Hi Abra
The upgrade is a very good idea,on a OdroidC1+ what component you would replace?
Regards
Olivier
I can not say it now. It is not even sure that C1+ will be chosen. But any SBC will be selected, we have to build a linear power supply first. Probably a battery power supply will also be tried. We have a few parts on stock to start with:
1. Linear Technology LT1963A and LTLT1764A regulators.
2. Motorola MBR 3045 and Cree C3D02060 silicon carbide diodes
3. Tantal resistors
4. Black gate caps
5. Lithium polymer battery with control panel.
Sorry, I'm not a predictor. But later I can tell what we done and maybe why.
1. Linear Technology LT1963A and LTLT1764A regulators.
2. Motorola MBR 3045 and Cree C3D02060 silicon carbide diodes
3. Tantal resistors
4. Black gate caps
5. Lithium polymer battery with control panel.
Sorry, I'm not a predictor. But later I can tell what we done and maybe why.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.