ASR Open Source Streamer Project

[Skeptischism]

I already was before you made that post

 

[Music1969]

you havent read any of the thread for some time, have you?

LOL you are right. If this below is the current status (a multichannel USB DAC !?) this is way more exciting than the earlier discussion.

 

[Skeptischism]

Yes. I saw the thread and saw potential to work the 2 together, since there are very few high quality options in that area. weve spent some time going around and around with spec, because its slim pickings for SBC's that support multichannel i2s output and none that are supported (currently) by the likes of volumio and MoOde,. I bit the bullet and just started designing a dac board more specific to the needs and budget here that combined elements of the higher priced and more involved design i'm working on, allowing me to use it as a test bed and also potentially create a separate design for a wider market than there is for a high priced solution like I am building for myself (which was and is the impetus for me, rather than being strictly commercial endeavor) I also decided I would move more quickly on the USB aspect in parallel too, given how slick the RPI and MoOde/CamillaDSP solution is, it will make for a powerful streamer with DSP. The guys are also going to have a bash at getting that running on the RockPro64/Rock64, which has multichannel i2s and that would also work with the i2s input dac board.

A fire was lit under my efforts in the last couple of weeks too, because I knew I was starting a new job and would not have as much time available to me. I wanted to have a solid basis an direction before things got too busy.

 

[tinnitus]

What s about a DAC with HDMI LPCM input? RPI can do 8 channel out over HDMI.

 

[Skeptischism]

at 48khz and only with matching (and expensive) chipset, at which point you may as well use usb and xmos. the only 8 ch i2s or whatever it is, output cards are kludges/hacks and there is no MCK input for rpi that way like i2s. no official HDMI cards are legally allowed to expose the LPCM.

 

[notabenem]

@phofman does the UAC2 gadget mode of the USB driver allow for a full-duplex mode of operation? In other words, can I have both input and output channels at the same time, with different sample rates? Do we have a potential of building a complete USB audio interface using it?

 

[Skeptischism]

while youre at it guys, @phofman remember that query about doing USB gadget mode over ethernet? for the neurotic types, you could even use fibre ... lol. an ethernet gadget that was indistinguishable from a usb gadget would be awesome. high speed, ground isolated USB audio DSP. wired is fine too of course. transformer isolated. magnetics is of course how you would achieve isolation of i2s, but in that case it is not without it's gotchas, having ethernet handle the isolation at that level would be cleaner if it's doable. Do you guys want isolated i2c? that would be simple enough to achieve and is the plan.

How reliable is an estimate of a round trip with such a thing (ethernet packets) do you think, for video sync etc? we are aiming to solve that as well for the streamer, playing video, with digital HT crossover?

obviously you can measure and then add the delay to the video in something like VLC, but is there a way to hard-code a delay on ANY and ALL outgoing video, to match the crossover processing and analogue loop delay? and could this delay profile for each sample-rate and filter setting be swapped on the fly, just as audio clocks can be? the same signal could drive both clock FS setting (and display) info and match it to the known filter to calculate the delay? I know camilla requires refreshing for a sample rate change, but my understanding is this is only partial and can happen reasonably quickly?

Lastly, what is everyone using for a microphone for speaker measurement?

 

[Skeptischism]

Ah, I also need to clarify my post on the previous page (too long ago to edit), the IV stage response would be fairly flat out to 90-100khz, but obviously whatever digital filter you use will roll it off well before that.

 

[voodooless]

by the way, i'll post a teaser pic in the next couple of days of where i'm at with the new 8 channel board. It's starting to shape up. No XMOS schematic as yet, still working on the analogue stages and elements of the onboard power supplies. I've been very busy all week at a new position, so only just opened the layout again tonight.

Exciting stuff

Regarding control of the ESS: IMHO this should be done through the Xmos, so that the only real interface to the Pi is USB. I guess there are all kinds of USB audio control mechanism for this available to (miss)use. Volume control can also be done that way, both master as per channel.

Display: I don't care

SMD usage: think it's a very sensible idea.

Does it interest people to implement a higher current buffer on the output of 2 channels, so that it could be used as a high spec balanced headphone amp on those 2 channels?

For me, not of interest, but others might feel differently. I can imagine that you have a speaker and headphone setup that you can switch using DSP profiles.

On that note, what connectors are people going to use to connect to their amps? XLR? just those connectors would be bigger than the dac board. i'll probably use mini XLR, lemo, or a mixed signal DSUB wiring harness like used on PCI soundcards (could include a power-good signal for sequencing power).

XLR and RCA will the ones that are mostly used. Mini XLR is little used, adapter cables are always more expensive. You could just have the mini XLR layout and then have the option to either make them with or without connectors.

Lastly, what is everyone using for a microphone for speaker measurement?

I guess the MiniDSP microphone is quite popular.

For me, to be useful to me, I'd need digital input as well so I can connect TV, media player, external streamer or legacy CD player etc.

Also important: any idea about the pricing point of the final product?

 

[buz]

How reliable is an estimate of a round trip with such a thing (ethernet packets) do you think, for video sync etc? we are aiming to solve that as well for the streamer, playing video, with digital HT crossover?

IP round trips in wired Ethernet are generally sub 1ms, no issue with lip sync by itself whatsoever (that by itself is a lot less latency than your usual TV has to begin with). If you run 60p video, you have 17ish ms per frame, after all. WiFi is a bit more complicated, but I'd generally still assume less than 10ish ms roundtrip even for not so great cases.

Maybe I am missing something, but digital input seem like a problem to be solved with a hat on the rpi?

 

[notabenem]

while youre at it guys, @phofman remember that query about doing USB gadget mode over ethernet?

Isn't AVB about 'sound over ethernet'? https://en.wikipedia.org/wiki/Audio_Video_Bridging

EDIT: And here's an in-depth guide getting it to work in Linux: https://tsn.readthedocs.io/avb.html

 

[phofman]

@phofman does the UAC2 gadget mode of the USB driver allow for a full-duplex mode of operation? In other words, can I have both input and output channels at the same time, with different sample rates? Do we have a potential of building a complete USB audio interface using it?

Of course.

Linux 5.12.0-rc6-v8+ with fe980000.usb Linux USB Audio Gadget at usb-0000:00:1d: USB Audio

Playback:
Status: Running
Interface = 1
Altset = 1
Packet Size = 864
Momentary freq = 192000 Hz (0x18.0000)
Feedback Format = 16.16
Interface 1
Altset 1
Format: S24_3LE
Channels: 8
Endpoint: 1 OUT (ASYNC)
Rates: 48000, 96000, 192000, 512000, 768000
Data packet interval: 125 us
Bits: 24

Capture:
Status: Running
Interface = 2
Altset = 1
Packet Size = 582
Momentary freq = 768000 Hz (0x60.0000)
Interface 2
Altset 1
Format: S24_3LE
Channels: 2
Endpoint: 3 IN (ASYNC)
Rates: 48000, 96000, 192000, 512000, 768000
Data packet interval: 125 us
Bits: 24

 

[phofman]

Ad AVB - I have not found any feedback channel for soundcard clock synchronization https://avnu.org/wp-content/uploads...-Video-Transport-Protocol-AVTP_Dave-Olsen.pdf . IIUC it works similarly to rtsp which has clock timestamps too. But the question is how to align the incoming clock timestamps to the actual soundcard samplerate. Gstreamer does it simply - dropping excessive samples or linearly interpolating missing samples. I do not know if this is the method you would accept for your project. Or quality adaptive resampling as performed by CamillaDSP... introducing unaviodable latency, certainly not for AV lipsync without explicit delaying video.

Latency of the USB gadget will be considerable too (3 alsa devices with buffers in a row). DSP in camillaDSP will certainly be larger than acceptable max. lipsync delay without explicit video delays.

XMOS without any DSP can potentially be OK as it is not processing audio samples in batches but continuously using its dedicated HW, having only small buffer for the explicit async feedback feature.

 

[somebodyelse]

Isn't AVB about 'sound over ethernet'? https://en.wikipedia.org/wiki/Audio_Video_Bridging

EDIT: And here's an in-depth guide getting it to work in Linux: https://tsn.readthedocs.io/avb.html

Note the requirement for a network interface with hardware timestamping which is relatively unusual. That's why there's explicit mention of the i210 in there. The Beaglebone Black is an option for SBCs, but the Pi isn't. AES67 and Dante don't have this requirement so can be used on a wider range of hardware.

 

[notabenem]

Note the requirement for a network interface with hardware timestamping which is relatively unusual. That's why there's explicit mention of the i210 in there. The Beaglebone Black is an option for SBCs, but the Pi isn't. AES67 and Dante don't have this requirement so can be used on a wider range of hardware.

Right. Also requires AVB compatible Ethernet switches. Not good.

 

[Skeptischism]

Sorry guys, really been waylaid, I had typed the below last night but wasnt finished before I had to crash. I see phofman has covered a bit of the same ground, but I dont have time to edit ad type again, so youre stuck with mostly yesterday me . this commute is killing me. I'll hit you guys up tomorrow night.

@buz i'm not talking about latency of round trip of wired ethernet by itself, but rather as part of what would be ethernet acting as asynchronous USB gadget. you see, the USB gadget mode can theoretically be used with ethernet in place of USB, so i'm not sure how the fifo works and what size chunks, I presume there would be some sort of fifo, or more than one involved with using ethernet. then you have the time required for the filter to be calculated and if you are using FIR, or mixed FIR/IIR, meaningful latency is introduced and it needs to be accounted for in the video delay. we arent talking about a system that already has both the audio and video information at the same time in the same stream. we have the video, coming in in a stream, but the audio must be taken out, processed; with a resulting delay that is impacted by complexity of filter, sample rate etc and then the video delayed by that same amount, plus (or minus) the difference between the USB audio output and the HDMI video output. these delays can be calculated for the most part, but also measured via the difference between the processed audio and a loopback. You could do that any time you added a config. Also, video would not be leaving via ethernet

so ive got somewhat conflicting answers all over . headphone amp, no headphone amp, xmos, no xmos, onboard control, no onboard control, i2s input only, bare bones control XMOS control and USB input. and no BOM and design isnt finalised, so no, no price guys. I have been clear what has to happen before i'm willing to do that and yet people are pushing, I also need to measure the 2 channel IV stage board before I commit to building a multichannel design using the same parts. I may end up having to add the buffers anyway, but I shouldn't have to. Originally I told you guys i'd have something in july. it's flattering you are so keen to see if it will work for you budget, dont get me wrong. just please understand.

spdif you can easily add somewhere else in the chain if you need it. I may and I stress may, do something in the xmos, but it needs to be fed to the DSP, since its 2 channel ..., so really the place for it is on the rpi, or a hat on the rpi, as that is effectively no load on anything and it would have to be fed back there for processing anyway, right? seems like a lot of trouble and expense going full duplex for that. the dac board will not be connecting on the GPIO headers, so you can add whatever you want there. It seems like an odd place to take your spdif input from, yes you can do duplex apparently on the xmos, but i've seen more people get it wrong than right.

I did ask for feedback, so I shouldnt complain; but please dont keep asking me for pricing while that is happening ... only an idiot would put a price forward while the goalposts are still moving and I will not have time to price up multiple options including some second source. given what's been happening with the supply chain.

regarding load and delay, it'll be a matter of sucking it and see, but I would like to somehow achieve it if possible. Its a nice to have, sice I dont [personally have room for 2 systems at home and i'm sure others would appreciate it too. I dont want to use xmos for anything bar USB->Mch-i2s and maybe some volume control and I2C. the video is a nice to have and you can do a passable job of low delay with just xmos and keeping the filters setup for that mostly IIR. there will be some, I just wonder what the best mechanism is for knowing what it is, so that it can be accounted for.

btw, I saw your win on gadget mode phofman, congrats.


me again ... tonight me that is
I knock off early tomorrow, so i'll catch you tomorrow evening. it's nearly midnight here.

 

[voodooless]

Sorry guys, really been waylaid, I had typed the below last night but wasnt finished before I had to crash. I see phofman has covered a bit of the same ground, but I dont have time to edit ad type again, so youre stuck with mostly yesterday me .

Hi yesterdays @Skeptischism !

so ive got somewhat conflicting answers all over . headphone amp, no headphone amp, xmos, no xmos, onboard control, no onboard control, i2s input only, bare bones control XMOS control and USB input.

Well, what did you expect? Did you read the last 24 pages ?

spdif you can easily add somewhere else in the chain if you need it. I may and I stress may, do something in the xmos, but it needs to be fed to the DSP, since its 2 channel ..., so really the place for it is on the rpi, or a hat on the rpi, as that is effectively no load on anything and it would have to be fed back there for processing anyway, right?

Yes, but it adds more extra cost than designing it in. Also it would be an advantage to have it in the ESS clock domain already, since that saves an extra ASRC step on the Pi (obviously you need to do ASRC on the board then). I think the Xmos has native SPDIF functionality, so should be easy to add. ASRC is can also do.

yes you can do duplex apparently on the xmos, but i've seen more people get it wrong than right.

No idea about the complexity. The Okto people did it at least.

I did ask for feedback, so I shouldnt complain; but please dont keep asking me for pricing while that is happening ... only an idiot would put a price forward while the goalposts are still moving and I will not have time to price up multiple options including some second source. given what's been happening with the supply chain.

I understand where your coming from, but I have to disagree. I'm not even asking for an exact set price, but a ballpark figure. Is it somewhere near $€ 199, 399, 699 or 999? The first thing to check when designing a product is what people are willing to spend on it. If we're poaching 999, and a nice casing and PSU is missing, then most people will probably be better of buying an Okto 8. You get a warranty and everything . So in that sense, price should also be just another goalpost. Obviously, it also depends on your own goals. If this is more of a personal project that you want to share with others, I can understand that price might not be a priority. But from an "ASR Open Source Streamer Project" vantage point, it probably is.

Before moving on, it would be actually good to first stop moving the goalposts. That is obviously not easy to as we have all seen here , but it will help to stabilize the design and get some focus on the work to be done. To do this in a more structured way, a survey could be made to see what features are actually popular, and what people would be willing to pay for them (if at all). The other option is to ignore everybody and just do your thing .

 

[notabenem]

Before moving on, it would be actually good to first stop moving the goalposts..

True. It would be good if we had a sticky post that we'd update in terms of status and architectural/design decisions.

Roughly something like this:

Status:

1. HW design: in progress
2. SW:
   1. Platforms SW: relying on existing SW. CamillaDSP, Moode, Linux.
   2. Custom development: not started yet.
3. Cost target: none. Reason: post 463

Architectural & Design decisions:
We do:

1. A multichannel DAC with very limited features on top of being a high quality DAC
2. a ready-made and assembled DAC board based on the ES9028PRO and whatever is needed to achieve the desired quality objectives
   • 8 ch LINE OUT (through TASCAM DB25 8)
   • using freeDSP recommendations, where suitable
   • Pinouts for volume control
3. Connectivity: primarily USB UAC 2.0. Stretch goal is Ethernet.
   • Either based on XMOS (low latency, but requires custom programming)
   • SBC in Gadget only mode. Requires mainline kernel and multichannel I2S pinouts. Latency is expected to be higher requiring explicit lip-sync for video. *1
4. Display & Volume:
   • DIY - SBC/Arduino using the designed pinouts on the DAC board.
   • through XMOS, built-in (subject to programming)
5. Stretch goal: AUDIO IN

We don't do:

• An ALL-IN-ONE streamer (Networking, Decoding, Configuration, DSP, DAC),
  • SBCs with necessary multichannel support are not supported by existing SW (moode, volumio, etc).
  • At the same time those SW already do what we need (room DSP, speaker DSP, decoding, streaming) on their supported boards.
• VU meters. AMPS should do this to identify clipping.
• Headphone amps.
  • Use an external headphone amp connected to the balanced outs
  • Configure CamillaDSP to use Channel X and Y as targets for the headphone amp, and do whatever processing is necessary.
• Case

*1: AFAIK, only boards based on RK3308 and RK3399 are candidates. However, from those only the RK3399 has a mainline kernel for the gadget mode.

• Rock64/RockPro64 boards are possible candidates. Too bad other SW (OSMC, Moode, Volumio) do not support them (or consider dropping support). KODI works OK.
• The RockPi S does not have a mainline kernel. Gadget mode is not available.

Edit: to avoid confusion, RPis = RockPi S (https://wiki.radxa.com/RockpiS)

 

[somebodyelse]

The RPiS does not have a mainline kernel. Gadget mode is not available.

Gadget mode is available on the Pi (zero and 4), and Ruslan's pending patches for the feedback endpoint have been tested on it. The reason it's not suitable is the I2S only supporting 2 channels.

I think there's a bit of confusion around this area and the different uses of an SBC. If the SBC is acting as an alternative to an XMOS then it needs gadget mode and multichannel I2S support, but little processing power as the DSP is done at the host end of the USB. A Beaglebone Black might fit the bill. In this role it doesn't need support for Moode etc. which will be running at the host end, not the device/gadget end.

 

[phofman]

When using the gadget mode, camillaDSP would most likely run OK on any SBC but the single core ones (and maybe even on those). The gadget can be configured to offer 2ch with DSP and multichannel with no DSP. A code monitoring capture/playback rate difference and adjusting the USB async feedback control of the gadget alsa device will be required anyway, with camillaDSP fitting the bill soon (camilla already supports the similar feature for snd-aloop devices, Henrik is already playing with the gadget). Or for plain passing samples between the gadget capture and I2S playback devices the alsaloop modified by Ruslan could be used.