ASR Open Source Streamer Project

[voodooless]

That doesn’t sound encouraging, specially if it turns out it can only do 48 kHz. The USB option just seems like a much safer bet.

Looks like the Nvidia Jetson platform does support proper TDM: https://forums.developer.nvidia.com/t/tdm-mode-on-the-i2s-port/67452

Upto 8 channel 32/96 seems to be possible.

Or, if we really want to go hardcore: https://rocketboards.org/foswiki/Documentation/NetworkedProAudioFPGASoCDevelopmentKitByCoveloz

final edit: how actual is that information on the pi? In the BCM2711 product brief, it says it supports TDM?

 

[phofman]

That doesn’t sound encouraging, specially if it turns out it can only do 48 kHz.

RPi I2S does 384kHz/2ch/32bit officially. That translates to 96kHz for the FPGA-enabled 8ch mode, as supported by the octo soundcard.

Looks like the Nvidia Jetson platform does support proper TDM: https://forums.developer.nvidia.com/t/tdm-mode-on-the-i2s-port/67452
Upto 8 channel 32/96 seems to be possible.

The Rockchip ASoCs (e.g. rock64) do 8ch out/in at 192kHz. E.g. this small inexpensive board https://wiki.radxa.com/RockpiS has all 4 I2S data out and data in lines on its pinheaders since v. 12 https://wiki.radxa.com/RockpiS/hardware/gpio#Hardware_V12 . Some of the linux distributions listed on https://wiki.radxa.com/RockpiS/downloads seem to have the latest kernel 5.11. I have not tried yet but rock64/rockpro64 boards look very interesting for multichannel embedded devices.

final edit: how actual is that information on the pi? In the BCM2711 product brief, it says it supports TDM?

Explained in https://www.raspberrypi.org/forums/...afeb48fb01989e95afb4ff4c2aa&start=25#p1219382

 

[Skeptischism]

You da man, phofman!! I knew youd have all the info. Thanks so much for joining up over here just to contribute! much appreciated.

I actually have an old pine64 around here somewhere, donated by a friend, I was excited as rockchips have been used for audio very successfully, but I think I found the particular board I had was neutered low end model. i'll have to dig it out and double check.

@voodooless, we all know USB works, but I would like to avoid it if possible. it reduces hardware cost, bulk, power supply, driver and programming and anyway, there arent exactly an abundance of suitable USB drivers either. it also reduces load on the USB bus, which has shown to be a bottleneck in the past, causing dropouts, especially running multichannel through it.

 

[voodooless]

@voodooless, we all know USB works, but I would like to avoid it if possible. it reduces hardware cost, bulk, power supply, driver and programming and anyway, there arent exactly an abundance of suitable USB drivers either.

Not really. Drivers are already in the os, they generally work out of the box, no programming involved. For direct multichannel on the pi you’ll need to make special drivers to make it work, and another programmable logic chip between DAC and pi. That adds cost and complexity. A solution with a xmos would be more versatile and flexible, and probably much less effort to program.

it also reduceer load on the USB bus, which has shown to be a bottleneck in the past, causing dropouts, especially running multichannel through it.

Yes, we know the pi 3 USB is buggy. The pi 4 is not. And from what we know about how reliable the multichannel i2s/tdm solution is with the stuff that is already out there, it’s clear that USB is more stable. That doesn’t mean it couldn’t be done, it just needs a hell of a lot more engineering.

 

[notabenem]

That RockPI-S is limited to just 512Mb. Hopefully that'd be enough. If not, the RockPI 4 has up to 4GB.

Edit: RockPi 4 does not feature an 8ch I2S.

 

[phofman]

IMO RPi with its 2ch I2S is not a technically correct choice for a multichannel embedded device. That multichannel TDM hack is complicated, likely unreliable (signalling the 0/1 stereo pair in the trigger method to the FPGA via GPIO) and requires a multichannel DAC with TDM input (while several stereo DACs (e.g. inexpensive ESS9038Q2M?) may be a better option).

If other ARM boards with proper multichannel I2S of comparable price, performance, and support in the mailine kernel (no ancient 4.4 android kernel) are available, IMO they should be explored first for a multichannel device. USB is internally very complicated (HW+SW/firmware), therefore expensive, and IMO should be used as last resort for an embedded design, only after the technically proper method - I2S - fails to deliver. But that's only my view.

 

[notabenem]

@phofman yeas, I have just realized. Apparently the RockPi 4 has only a single i2S.

 

[voodooless]

That RockPI-S is limited to just 512Mb. Hopefully that'd be enough. If not, the RockPI 4 has up to 4GB.

But the RockPI 4 does not have multichannel I2S on the 40pin header, nor anywhere else (well, on some pins it has), at least not as far as is documented. Only the 2 channel version is fanned out.

It does have a major advantage though: it offers an M2 slot, so you can put in an SSD. Even a very cheap one would be more reliable than an SD card (given that it used the PCI-e bus, not any of the legacy features).

 

[Skeptischism]

There are still quite a few reports about USB recording interfaces not working in linux then? Even some with class compliant drivers seem to struggle. the Focusrite scarletts seem like a decent choice on linux. Buggy or not, it is still using PCI-e lanes and resources where they otherwise would not be (especially when there arent many to start with on RPI) is using resources and funds that could be used better elsewhere. these arent powerful computers and I know well how budget conscious ... er ... stingy this place can be


I'm not stuck on the pi, I dont even own one (yet). I am working on a 2 channel q2m dac i'm looking to team up with one, but thats a different tangent to this. Designing an I2s input board is all that's on offer from me any time soon, i'm afraid. One of my prototype multichannel dac boards, sans control, may suit nicely, or a layout may be repurposed to suit without too much work, but since i'm in the middle of designing 2 different multichannel DAC boards which will likely end up with isolated XMOS input, I have my own wishlist and timeline for that project and I suspect the budget may not suit.
(one 6-8 channel with 2 x 9038PRO at the moment and with any luck, i'll have some ROHM BD34301EKV-E2 in a couple of weeks, so one with 2 x BD34301EKV-E2 for 4 channel)

I thought i'd ask about rpi again, since it is still the preferred SBC for a larger audience and there are builds like Moode etc ete that are just ready to go, with all the DSP included, but agree, technically and for myself, other boards with possible multi channel i2s should and will totally be explored before USB. You guys have got to remember i'm coming at it from the POV of designing a board from scratch, with as few hacks as possible.

 

[voodooless]

There are still quite a few reports about USB recording interfaces not working in linux then? Even some with class compliant drivers seem to struggle. the Focusrite scarletts seem like a decent choice on Linux.

Oh yes, for some reason it seems to be hard to actually create something that is fully class compliment, from both sides (kernel and device side). But I think the Xmos guys nailed it quite well. Hear little problems from devices using Xmos chips (like Octo). On the other hand MacOS seems to have nailed the driver side very well. Just about all devices seem to work out-of-the-box without any drivers (except for special features outside of the class compliance). Could also be because the manufacturers don't want to ship devices that don't work on MacOS of course.

Buggy or not, it is still using PCI-e lanes and resources where they otherwise would not be (especially when there arent many to start with on RPI) is using resources and funds that could be used better elsewhere. these arent powerful computers and I know well how budget conscious ... er ... stingy this place can be

What else would you use the PCI-e lanes for, a USB connected SSD? Connect it to the USB 3 ports, and leave the audio interface on the USB 2 ports. Do you think a link with a few Gbit/sec bandwidth cares about your low-speed audio interface? It will be barely noticeable. So no, these are powerful computers. Especially compared to what I'm dealing with on a daily basis.

I thought i'd ask about rpi again, since it is still the preferred SBC for a larger audience and there are builds like Moode etc ete that are just ready to go, with all the DSP included, but agree, technically and for myself, other boards with possible multi channel i2s should and will totally be explored before USB. You guys have got to remember i'm coming at it from the POV of designing a board from scratch, with as few hacks as possible.

I'm not so sure about the priorities here? I think the advantages of the Pi are very clear: it already offers lot's of ready to go software, is cheap, easily available and well support. On the other hand, we know that multichannel audio over the 40 pin header will probably add a few major nightmares along the way, and it might never be stable. That leaves two major options: the USB route, or look for a different SOC platform that has enough computing power to be able to do multichannel software DSP (so comparable to the Pi 4) and offers either TDM or multiple I2S channels in hardware. That will give you a SOC platform that most likely does not support any of the existing audio-centric distributions out of the box, meaning efforts need to be made to port it to the new platform (and then we can argue about which one to pick ). That will take quite a few resources.

 

[Skeptischism]

the 9038PRO layout, but with just one dac, could work, for example. and using the es9311 dual regulator to keep costs down vs the pricier ltc6655+LT3420 or optionally opamp based shunt AVCC regs i'm using for mine (trying both and seeing if the difference is meaningfully measurable). those damn LT references are pricy now!! I bought a strip some years ago and they were only $5 each, they seem to be double that now putting the BOM for those regs alone at over $25 a piece in small volume.

 

[voodooless]

It might be interesting to do a poll on how much money people are willing to spend, and on what? I mean: spending $€£ 400 on an 8 channel DAC board, or $€£ 600 on a DAC+case is a different matter. And for 600, you're already very close to something like the Okto, with proven performance. So I think the price point should be quite a bit lower than that in the end, but that is just my opinion. Personally, I also don't need a 120 SINAD DAC, anything beyond roughly 110 I would be fine with (could be another poll ). If we know what people are willing to spend, something can be engineered that fit's that budget.

 

[Skeptischism]

yes, but all that software work for i2s is someone elses problem , i'm the hardware guy and design guy (and yes, i'm on mac too, so i'm spoiled with proper driver support). I'm pretty clueless when it comes to programming, so my partner in crime will handle the software side of things, regardless of what hardware we end up on and regardless of whether it ends up as a product. We are designing to satisfy ourselves first.

the rpi has been sitting in the background as a grown up DSP platform for years, with FPGA or rpi. I love the software support and i'd love to embed an rpi compute module (or 2) and have it able to work as DSP, but there are roadblocks; always roadblocks. the priorities are predominantly time flowing in a linear fashion. the 2 channel q2m and then multichannel dac boards and clock/distribution etc will be finished first and I will at that point try to interface with any available options, before moving onto FPGA and XMOS solutions.

from what I garner, the XMOS isnt the greatest platform solution either, but widely adopted and given there are code blocks available, as you say, its cheaper and easier to get into vs the expensive but much more powerful xilinx, or cypress FPGA. The ROHM dacs dont have quite the SINAD of ES9038 (-115dB using their eval in stereo IIRC), but they are right up there and with any luck, no ESS hump like issues to fix. I'm actually really looking forward to working with a new DAC, from a company that isnt ESS ... but at $115AUD a piece and needing 2 for 4 channels, puts it outside your expectations I would think. It depends, ESS is pretty demanding when it comes to surrounding circuits, so it may end up about the same, but only 4 channels. Indeed, it would be about deciding at is acceptable, performance and price-wise, and seeing if we can get over the line.

I would hope to match the Okto and I wouldnt be posting here if I didnt expect it to be measured , I would look forward to it, but i'm performance driven, more than I am value driven. I'm not looking to undercut the OKTO (but that doesnt rule out compromises, if we can decide on them). i've been using similar IV stages with the opa1632dgn for years and its an amazing chip and he's clearly done a great job with the layout, but i'm trying a few 'new' things on these designs.

 

[notabenem]

Isn't it possible to create a USB -> N-channel I2S using an Arduino? Libs are available at least for Audio Class 1 (96Khz). Has plenty of Digital I/Os to be used for multiple I2S data signals while using the same clock source.

 

[voodooless]

yes, but all that software work for i2s is someone elses problem , i'm the hardware guy and design guy (and yes, i'm on mac too, so i'm spoiled with proper driver support). I'm pretty clueless when it comes to programming, so my partner in crime will handle the software side of things, regardless of what hardware we end up on and regardless of whether it ends up as a product. We are designing to satisfy ourselves first.

Must be an easy way of living . I'm haunted with too much knowledge on all parts, so am always torn apart between multiple compromises

The ROHM dacs dont have quite the SINAD of ES9038 (-115dB using their eval in stereo IIRC), but they are right up there and with any luck, no ESS hump like issues to fix. I'm actually really looking forward to working with a new DAC, from a company that isnt ESS ...

We badly need AKM back! But more competition would be even better That ROHM stuff is not cheap btw

Isn't it possible to create a USB -> N-channel I2S using an Arduino? Libs are available at least for Audio Class 1 (96Khz). Has plenty of Digital I/Os to be used for multiple I2S data signals while using the same clock source.

I doubt that would be possible. As far as powerful systems go, this is definitely not one Also, you'd need Class 2, which is quite different.

 

[notabenem]

... I doubt that would be possible. As far as powerful systems go, this is definitely not one Also, you'd need Class 2, which is quite different.

All right, then. Since someone mentioned the freeDSP project, I see they have quite a list of devices. Like the Aurora, for example. But apparently it can't be bought?

 

[Skeptischism]

they are all based on AKM chips, so they will need a redesign, as those parts are not available.

 

[notabenem]

I know they are using AKM, I was just under the impression, that the shortage is not going to last much longer. Other plants started offering their capacities. So maybe, just maybe, by the time we finish the theoretical discussions here, chips will start to become available?

 

[Skeptischism]

No, as far as i'm aware its looking like 2022 at the earliest for their audio portfolio. they cannot so easily find a fab set up for producing that line and it is not their main business $$$

 

[Skeptischism]

and i'm moving forward regardless, whether its theoretical for you guys is up to you