I tend to agree.
while the i2s stuff on the 'pc' sounds interesting, I would rather trust a well designed usb UAC2 dac or usb/spidif or even usb/i2s converter.
my guess (just a guess) is that i2s won't buy you anything in audio that you can't already get (better) via uac2.
but it would be fine to be proven wrong
whatever gets us decent quality i2s or spdif is great for us all.I'm still waiting for a breakthru on usb stability on the pi, though. until this is fixed, the platform is mostly useless (I got tired of sd card corruption and suspended my use of this platform for now)
I need to play stereo CD content, so I want to feed my PMD100 and TDA1541A with I2S. There's no point converting to USB or SPDIF, just to convert back to I2S to feed a DAC chip - if you can help it. Think of all the jitter!
I suppose, if you have lots of 7.1 content, then you may have different requirements.
(please, no arguments!!!!)
However, like yourself, I'm also at the point that it's not a solution until it's working with DMA in kernel space. I can't use what I have with MPD for instance. But, hey! This is DIY after all.
Anyway, Raspberry Pi • View topic - I2S: Anyone got it running?, shows the code changes I made.
I suppose, if you have lots of 7.1 content, then you may have different requirements.
(please, no arguments!!!!)
However, like yourself, I'm also at the point that it's not a solution until it's working with DMA in kernel space. I can't use what I have with MPD for instance. But, hey! This is DIY after all.
Anyway, Raspberry Pi • View topic - I2S: Anyone got it running?, shows the code changes I made.
I'd rather have an spdif carried data stream than a poorly done i2s one.
my understanding is that unless you do i2s VERY well, its going to be suboptimal compared to spdif.
with reclocking dacs, I don't see the urgency in i2s like it was 10 or more years ago. reclocking and rebuffering is what makes the spdif quality mostly irrelevant. as long as no bits get lost, the receiver is now responsible for timing. the pc is not the critical path anymore, its just pushing data (again, talking uac2, here).
for example, would I trust the audio widget to clock out data at very low jitter rates? or would I trust a $35 rasp pi that was NEVER thought of as a high end audio transport?
I have some appreciation for the design and work that went into the audio widget. I don't think that kind of care went into the soc or the pi. it wasn't its focus, afterall, it was more a video player source and the target audience is not expecting very expensive sounding audio from it, especially not over i2s.
sometimes, vendors add features just to say they have them. I'm thinking i2s is such a thing on this soc device.
my understanding is that unless you do i2s VERY well, its going to be suboptimal compared to spdif.
with reclocking dacs, I don't see the urgency in i2s like it was 10 or more years ago. reclocking and rebuffering is what makes the spdif quality mostly irrelevant. as long as no bits get lost, the receiver is now responsible for timing. the pc is not the critical path anymore, its just pushing data (again, talking uac2, here).
for example, would I trust the audio widget to clock out data at very low jitter rates? or would I trust a $35 rasp pi that was NEVER thought of as a high end audio transport?
I have some appreciation for the design and work that went into the audio widget. I don't think that kind of care went into the soc or the pi. it wasn't its focus, afterall, it was more a video player source and the target audience is not expecting very expensive sounding audio from it, especially not over i2s.
sometimes, vendors add features just to say they have them. I'm thinking i2s is such a thing on this soc device.
yes there is very much a reason to use USB, the i2s you get out of this thing is never going to be great. i2s for i2s sake is a fool's errand, thinking that less is always more in this situation is not taking in the whole picture. i2s can easily be worse than anything else out there including optical, in fact in this case with unknown power supply quality/noise and clock jitter, even optical is almost guaranteed to be better and LOWER jitter given a proper spdif implementation. add in using a NOS dac and you have a recipe for awful quality.
i2s is the least resilient of the digital audio formats, clock jitter, noise, ground bounce etc are all passed through, no error correction, all single ended...we can bet that the i2s on the Pi is not going to be properly terminated either
if thats your motivation for using i2s, I dont think youve really thought this through, usb will be leagues ahead, i2s was never meant to be an interconnection scheme between different modules.
give me USB with UAC2 anyday for this purpose, you need all your ducks in a row for i2s to be great, and it has to be local; then it is the way to go
haha I see linuxworks has said pretty much the same thing while I was making coffee, oh well it stays, just to reinforce the point.
i2s is the least resilient of the digital audio formats, clock jitter, noise, ground bounce etc are all passed through, no error correction, all single ended...we can bet that the i2s on the Pi is not going to be properly terminated either
if thats your motivation for using i2s, I dont think youve really thought this through, usb will be leagues ahead, i2s was never meant to be an interconnection scheme between different modules.
give me USB with UAC2 anyday for this purpose, you need all your ducks in a row for i2s to be great, and it has to be local; then it is the way to go
haha I see linuxworks has said pretty much the same thing while I was making coffee, oh well it stays, just to reinforce the point.
Last edited:
lol. yeah, we see things similarly, in this regard.
I'm not an spdif hater. it seems hating spdif is trendy, these days
I see it as a data transport, and if buffering and reclocking can be done well (any disagreement, here, anyone?) then why care about getting a crappy i2s to work?
before uac2, yeah, it would be worth getting into host i2s. but the uac2 was a game changer. the burden of setting timing is no longer on the host. that's a much better way to go.
I'm not an spdif hater. it seems hating spdif is trendy, these days
I see it as a data transport, and if buffering and reclocking can be done well (any disagreement, here, anyone?) then why care about getting a crappy i2s to work?
before uac2, yeah, it would be worth getting into host i2s. but the uac2 was a game changer. the burden of setting timing is no longer on the host. that's a much better way to go.
Whether you suspect its low jitter or not, I suspect it's not too relevant as I intend to pass the signal through an oversampler before it gets to the DAC. The DAC needs to be clocked properly, the rest is less important. However, I do also intend to feed PCM_CLK with my own clock, and I plan to power the Pi with a linear PSU.
I also plan to locate the pi in the same case as the rest of the DAC (which normally receives I2S from a transport, and sounds great), so it's not exactly using I2S as an interconnect.
However, I2S is unusable in it's current state, for software reasons.
I also plan to locate the pi in the same case as the rest of the DAC (which normally receives I2S from a transport, and sounds great), so it's not exactly using I2S as an interconnect.
However, I2S is unusable in it's current state, for software reasons.
happy for you yeah, but that seems like a lot of trouble to go to to use less....which is usually the case in these situations. With your only barometer being that 'it sounds great' with another random i2s source, i'm not convinced. . use the time and money where it maters, the dac. its a whole lot easier to clean up USB than it is i2s, same case who cares, if the PCB and termination is wrong for i2s, a whole world of pain can happen to i2s over a couple cm. you can bet even with an external clock you will be using the pi's PLL
Welcome to raspberry pi ground as audio ground in a single ended dac....
Welcome to raspberry pi ground as audio ground in a single ended dac....
Last edited:
I have built several DACs before, using I2S. You say USB is easier to clean up, how? It ends up I2S (or some variant) when it enters your DAC chip. So clean up your USB, but if the chip converting to I2S is adding jitter, then surely you're wasting time? How are you tidying up your I2S? In fact, how is your DAC powered? USB power? Walwart?
I like to build my own stuff, this being DIY after all, I2S is more straightforward to deal with from that point of view.
Not entirely sure why I feel I should be justifying my decisions.
If you feel I've highjacked this thread by talking about using the Raspberry Pi to do audio, then I'm sorry, I'll start a new thread (I thought this was a digital source thread, not PC based?).
I like to build my own stuff, this being DIY after all, I2S is more straightforward to deal with from that point of view.
Not entirely sure why I feel I should be justifying my decisions.
If you feel I've highjacked this thread by talking about using the Raspberry Pi to do audio, then I'm sorry, I'll start a new thread (I thought this was a digital source thread, not PC based?).
Neither I2S or async USB are "better". For those of us who build our own DACs, using I2S makes more sense, since the DAC chip inputs needs I2S or something similar. Going through USB to get to the DAC is easier if you are using an off the shelf DAC, granted, since I2S is rarely available as an input. If you are using your own DAC with it's own master clock (and that is the key) then I2S is simpler, more direct, and less likely to add jitter. Yes, I2S has to be done right. I use differential signaling (LVDS) to send I2S data on twisted pair wires from my modified Squeezebox Touch to my DAC and to send master clock signals form my DAC to the Touch. Completely error-free up to 2 meters of cable, using master clocks of 22M and 24 MHz, Touch I2S-out and Clock-in mods.
Phil I am very appreciative of your work. I am interested in using the Pi as a Squeezebox player driving I2S outputs while receiving an exernal I2S clock from my Dac. My Squeezebox Touch does this very nicely up to 96K, but even the most recent DIY kernals, Async USB Dac Experiments - testers wanted..., can't get 176K or 192K on the I2S lines from the Touch. Also, the Pi is $35, while the entire Squeezebox line has been discontinued by Logitech.....
Phil I am very appreciative of your work. I am interested in using the Pi as a Squeezebox player driving I2S outputs while receiving an exernal I2S clock from my Dac. My Squeezebox Touch does this very nicely up to 96K, but even the most recent DIY kernals, Async USB Dac Experiments - testers wanted..., can't get 176K or 192K on the I2S lines from the Touch. Also, the Pi is $35, while the entire Squeezebox line has been discontinued by Logitech.....
Hiya, I have a RPi at work but I haven't fixed it up yet. Intention is to stream music to my external dac (from 3.5 jack to coax using an adaptor).
I think it is possible to install android etc and, with a tablet/android phone, it is possible to use these as touchscreen remotes.
This will be perfect if so as I don't want a pc monitor permanently in the room so once it is initially setup I can lose the monitor (and just leave the device on I suppose).
I'm talking sense here? Has anybody done this (or is looking to do this?).
Essentially, this device will be my "squeezebox touch".
Thanks
I think it is possible to install android etc and, with a tablet/android phone, it is possible to use these as touchscreen remotes.
This will be perfect if so as I don't want a pc monitor permanently in the room so once it is initially setup I can lose the monitor (and just leave the device on I suppose).
I'm talking sense here? Has anybody done this (or is looking to do this?).
Essentially, this device will be my "squeezebox touch".
Thanks
Last edited:
I *think* you're talking sense but I'm no expert. I've read (somewhere) of a project that controlled the rpi with an app on an android phone. I've not seen any mention of Android on the rpi itself but then you don't need that? I'm following Raspberry Pi • View topic - I2S: Anyone got it running? for getting digital audio out of the rpi but it looks like it's hard. I'm happy to try USB too but I'm not clear whether that's working yet.
Is it possible to get a digital signal out of the 3.5mil jack? Do you have software to do that?
Is it possible to get a digital signal out of the 3.5mil jack? Do you have software to do that?
I am following this thread with great interest. Although a linux newbie, I have been around audio for a long time. The concept of adding a great clock for the i2s feed and back clocking the rpi sounds like a sweet little deal. Even if it could never compete in the big leagues, it seems a worthy undertaking for a streaming device.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.