Vetting an idea .. R-Car Starter Kit for High End Endpoint

[int03h]

HI there,

I have been following a long a little, and I have fiddled a little. I bought a MiniDSP kit with 2 end points and a switch, after buying a MOTU 8A.( awesome device ).

By way of background - my first PC sound card was a R2R that came out the parallel port on DOS, so low level work doesn't scare me, however, I am planning on investing my own funds to get this going and I would appreciate it alot if someone wouldn't mind shooting holes into my idea.

The MiniDSP is OK, but I lack the enthusiasm to get started on down this road with 4 year old silicon, and a more or less proprietary ASIC at it's core - like ATMEL you get locked into their toolset and dev chain, less than ideal.

Ultimately I believe AVB is stalled (from my perspective) where it is, due to the lack of player support (source transport). I see the connectivity part as being well developed but the consumer transport layer ( like a mp3 / flac player ) as a MAJOR short fall. AudioSciences VSC is absolute extortion at $1500 for a driver, and using something like a MOTU to "simply" put data onto a network for playback it great but complex/expensive. MiniDSP connected to a PC via analog defeats the purpose of having bit accurate encoding all the way to a DAC / unless you somehow go PCI-E to I2S to AVB to IS2 to DAC .. again .. painful.

Lots of people are using RASPI and other devices to stream and manage their DAC's via MPD. I love this idea. Using a PC and something like Foobar2000 would is fine too, but you need a Motu and/or AudioSciences $1500 card to do this via Windows ( not MPD ). None of the RASPI DAC solutions are good because they are all I2S based and all seem to need re-clockers because of their poor I2S, or use USB XMOS, again with re-clockers on the I2S.

RASPI - I2S: https://volumio.org/product/allo-kali-piano-2-1-bundle/ Or another way .. https://www.flickr.com/photos/135181977@N06/34765073911/in/album-72157681264061263/

Buying a MAC is an option, but that comes with all of its own challenges. I looked at MANY I2S capable devices including Nvidia Shield, Nvidia X1/X2, Intel's Galileo, etc .. None of them do AVB .. they would all have to come out I2S before they go to AVB.

Dante looks cool, but again: I am principally against vendor specific lock in, especially since the standards are all covered by IEEE etc.. aka AVB. I guess this is where the high end audio community ends up, i.e. #giving up looking for another solution.

Finally, my thought, what about using a R-Car M3 with Yocto as the AVB/MPD/JSTREAMER device (front end)? I realize It would be a MASSIVE overkill, but the price of the starter kit is still reasonable considering the other options, and I bet I could build a KILLER front end, if you I wanted to - X or HTML - whatever.

The reason I come here for your sage advice is this : I would have to personally fork out $500-800 for the starter kit ( I am already invested in the I2S DAC, switches, mixers and end points, so I think I have plenty of building blocks at my disposal already to get started.

So, my thought is to go AVB with no rate conversion etc until it hits the miniDSP end point with the I2S output to the DAC. i.e. it would still be bit perfect all the way through with no clock regens or anything until it hits the 2 channel AVB listener and going out via I2S. While more expensive, it would still be preferable (jitter wise) to having a RASPI with reclockers or a PC USB XMOS interface with reclockers, and a good alternative until a proper windows interface is developed as the transport. I have fiddled with Linux and a Intel 210 card, but since Linux isn't really real time (well not like Yocto), I think it's pretty much a non-starter. I did get PTP working etc.. but then I kind got the feeling I was going down the wrong path.

I suppose I should just go buy a Apple MAC and try to get MPD going on that, again it just feels like the same thing as doing it on a PC with linux. Now with the R-Car starter kit, it's all there, in one package. Media file onto AVB network , sent via AVB network to DAC and done... right !?

Are there any reasons this isn't doable? My experiences with Atmel, have made me really want to forego the XMOS development cycle and go with a platform solution instead. Obviously the I2S endpoint decoder would have to be an XMOS, but that's cool. Since it should be "simple", especially for 2 channel stereo high end audio.

Thanks for your time, input and patience. Apologies if this is not an "issue" or even a code commit, I hope you can understand where I am coming from, I couldn't find anywhere else to put this. So .. forgive me if I am not in exactly the right place to gather feedback.

PPS : The reason I am looking at the R-Car devices: I noticed a ton of kernel commits. So there is active development here, SPECIFICALLY in the Audio/Video i/o area - a HUGE plus especially since it is ALSO being actively worked on in Yocto.

The kits: https://www.renesas.com/en-us/solutions/automotive/adas/solution-kits/r-car-starter-kit.html

https://www.digikey.com/products/en?mpart=R0P7796ASK000S%23YJ1&v=559

[ahogen]

Since you mention Renesas, I'm not sure if you found these interesting repositories over at https://github.com/renesas-rcar. I am fairly new to AVB as well and don't know if these are working sets of code, but with the amount that's there, I would imagine something would work.

These repos looked particularly interesting:

• https://github.com/renesas-rcar/avb-streaming
• https://github.com/renesas-rcar/avb-mse
• https://github.com/renesas-rcar/avb-applications

[int03h]

I did look at them previously, VERY BRIEFLY. So this statement is a bit off the cuff: The impression I got, was that they were re-inventing the wheel with all that. Right now, it LOOKS like they are going down the "mainline" kernel commit route. I saw a bunch of commits for the various onboard peripherals specifically for the M3/H3 based line (which is what got me so excited). It makes this far more interesting, in my opinion.

http://elinux.org/R-Car/Boards/Yocto-Gen3 - Can't be simpler ! :)

This is the kernel work - it seems pretty extensive. The fact that is supports Wayland says a lot. https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/

A few examples: ( There are lots more ) https://patchwork.kernel.org/patch/9871939/ < -HDMI support https://patchwork.kernel.org/patch/9871981/ <- AVB on the Ethernet port

And the device tree for the SoC - AVB hooks are at lines 483 .. https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/tree/arch/arm64/boot/dts/renesas/r8a7796.dtsi?h=topic/ravb-gigabit-integration&id=8c4e72607a720b5fdb65276983df85a02dfc13d4

Pics of the proto boards:

[pinealservo]

You're right that there's no consumer-level support for AVB right now, which continues to make me sad as well.

If the MiniDSP endpoint you're referring to is the XMOS-based AVB-DG (which I'm guessing based on "custom ASIC" and "proprietary dev tools" comments) I wouldn't write off the platform so quickly. Although there's a learning curve involved and you do have to use the XMOS tools, there's WAY less code in the complete solution and it's far more capable at fast, flexible real-time processing than any other general-purpose microcontroller platform. The architecture is well-documented, the tools are free and have nice features, etc. It's got I2S in/out on a header, so you don't have to worry about analog links. You could hook it up to a Raspberry Pi or something and be all set, although a sound card driver for it would probably have to be written. Just configure the Pi as a I2S slave and you shouldn't have any "reclocking" issues.

Speaking of Atmel, their SAMV71 Xplained Ultra board has all the hardware necessary to be an AVB endpoint, and in fact the original contributors of the avtp_pipeline code also ported it to that specific board, although that was not part of the contribution. But the software package from Atmel comes with basic device drivers, so a port could be written independently.

The Renesas R-Car looks like it might work, but I haven't worked with it so I can't personally vouch for how well it might work. The avb-mse repository looks promising, but it's not clear from what I looked at how the media clock is measured and adjusted, although they definitely have at least the high-level bits of clock recovery implemented. Would probably do what you want, but is not a great price/performance fit for a headless media streaming implementation.

If I had several hundred dollars to spend on a board for getting high-quality audio on/off an AVB network, I'd probably buy one of these: https://www.xmos.com/support/boards?product=18334 or even one of these to function as a USB-audio to AVB bridge: https://www.xmos.com/support/boards?product=18230. I've done a lot of work with XMOS AVB endpoints before, though, so I'm already familiar with how to work with them.

I'm currently working on i.MX 6SoloX and i.MX 7Dual boards to get OpenAvnu AVB software working on them--they're currently working well enough to be stored media talkers, but clock recovery is not implemented yet.

You should know that there are still no standard Linux kernel interfaces for managing aspects of AVB other than gPTP, even if hardware has AVB support, so looking at upstream kernel patches doesn't necessarily help much. So there is currently a lot of "reinventing" going on where everyone who wants to support AVB in Linux creates their own custom drivers and other infrastructure for it. Most silicon vendors that sell chips intended to run Linux in the automotive space have Linux AVB implementations of some sort, but they're all custom and not always available beyond their automotive customers.

[int03h]

@pinealservo Yeah .. that's the problem, I am just not sure how much of the underlying *NIX infrastructure is glued together properly. I guess that is/was my question. How complete is the Renesas "kit"? It looks "generic" and the distro looks fairly complete ( on the surface ).

The XCORE dev kit looks extremely scary .. lol .. perspective I guess.

The Motu is doing a wonderful job of providing a thunderbolt interface to my PC, I wish I could just untether it, and build out an AVB network without having to bleed out of my eyeballs buying a APPLE MAC or a $1500 virtual NIC. I guess the other question is .. why does M$ not see his as a priority ? I know they love to take IEEE standards, twiddle them a little and call them their own, but seriously .. What's up with them this time around?

Before I bought the Motu I was building a Soekris DAC and my plan was to use a USB interface. I abandoned it in favor of the Motu - I sometimes regret not going with a Rednet (Dante). I guess the upshot here is that you can buy a $100 endpoint and fiddle. I am not sure Dante gives you that opportunity? @pinealservo You have motivated me to try and use the AVB-DG and go I2S to the DAC using the Motu as the talker. I have ordered a XTAG. ;) I must say .. the documentation from XMOS looks very very good. So .. with ANY luck I won't be looking for any hand holding. If I do .. please be gentle ;).

[ahogen]

I'd recommend the xCore-200 startKit from XMOS, if you can swing it. A little more configurability. You could use either a 10/100 PHY or a 1Gb PHY just by swapping out a sliceCard.

[pinealservo]

A cool thing about the XTAG is that it's just a normal XS-1 chip with a USB connector and xSYS header on it; it's got a USB bootloader programmed into it, and the debugger functionality is loaded over USB. You can see the code for it here: https://github.com/xcore/proj_xtag2

You could conceivably compile and load your own code on the XTag itself, although the USB bootloader is permanently programmed into its OTP memory.

Anyway, XMOS development can be fun, just take the time to get familiar with the XC extensions to C and how the multiprocessing model works with some simple examples before you dive in. It's all very well thought-out and documented, but it's different than most microcontroller concurrency models. The upshot is that the compiler can find more problems for you (including concurrency bugs) ahead of time than a standard C compiler can.

I have an old XC-1 devkit that I was able to use to generate a nice 800x600 VGA signal from without having to resort to assembly or cycle-counting hacks, and I also coded a PS/2 keyboard interface for it to create the beginnings of a monochrome terminal. They're amazing tools for doing things that require fast, precise timing from software. XMOS has also been involved with AVB for a long time and their implementation software has always been open.

[int03h]

Thanks for all the advice guys. I bought the ExploreKit, only because the StartKit and and Audio platform just look like an overkill for what I am trying to accomplish immediately. While I would love the flexibility of the other dev kits, for the moment, my requirement is simple. If get into it, I am sure I will get the slice kit.

I am going to close this, thanks for all the help!

[int03h]

PS : If any of you are Windows Insiders ... please take a moment and upvote this request for AVB support in Windows 10. https://aka.ms/L3m938

[int03h]

I know that I am now taking liberties and pushing my luck - but I would love to finish off this conversation with what is now my intended end state. I have looked at various other forums, no others seem to give me a more direct path to the answers I need to validate that I am on the right path.

@pinealservo, if I could avail myself of your time one last time, please ?

The parts I ordered after the discussions above are actually starting to arrive! :) The DAC arrived today, as did the XTAG. I guess the Starterkit will get here early next week. I have installed the timecomposer and I have this: workspace_avb_20150626.zip D4U-AVB_Dongle_Schematic.pdf My question : Should I bother trying to make the AVB-DG talk to the DAC or should I wait for the Starterkit ?

Bearing in mind, that I am going to use the Motu to put it all on the wire, and setup the mixing etc. I shouldn't need anything very complicated at all. Regardless of which listener hardware I use. Right?

I imagine the modules are similar, if not identical ? ( from the IDE ). Since my solution is the same. i.e 2 channel listener, some QoS for bandwidth reservation, same clocking, very basic IP setup (if any), no user interface, and all the data coming out 2 of the I2S pins (I guess it's like 5 libs). In reality how much of the work that I do on the one is re-usable on the other? i.e. AVB-DG vs StarterKit.

I am not terribly attached to the AVB-DG's since the Starterkit looks like better silicon, but obviously I am going to have to solder headers etc onto all of it, and if the Starterkit is going to give better results. (i.e. sound better) shouldn't I wait and start there? OR doesn't it really matter, considering it's I2S coming out of both devices?

Thanks again for all your advise and kind indulgence. I promise I will go away for a while and hopefully come back knowing a lot more about this stack and be able to add value.

For me ... early success is super important, and if I end up building something, just to throw it all away is going to destroy my enthusiasm ;).

[pinealservo]

You seem a bit focused on the idea of "better silicon" as a useful concept here. In fact, the newer XMOS architecture is better in some ways, but the older one is sufficient for the use here and the differences are not that important in this application. In a real-time system, there's no point to adding extra performance or capability once the system requirements are met. There's no extra audio fidelity or anything to be gained with the newer part; it just has room for more other stuff or perhaps doing more streams or other tasks simultaneously, or running some fancy DSP algorithms.

The AVB-DG is a custom-built board complete with software for doing exactly what you want to do. I believe they even provide the full source for it. So, you should absolutely hook it up to the DAC and get familiar with how it works. The DAC will sound the same whether fed from the AVB-DG or another I2S source. Having a working endpoint will help a lot in getting your other board up and running, which will require a bit more software assembly since it's not a custom-designed AVB board.

[int03h]

@pinealservo Yeah, I have been wondering about that. I guess it's like saying one FPGA will sound better than another. As long as it has enough gates to get the job done life is good. Unfortunately I never spent enough time in the RISC world to get a good understanding of parallel programming, and definately not in the the event driven space. So this type of hype: http://www.diyinhk.com/shop/audio-kits/111-xmos-192khz-high-quality-usb-to-spdif-with-ultralow-noise-1uv-regulator-wmanual-power-switch.html is what I am basing some of impressions on. Sadly, there is PLENTY of B$ going round in this (the "pro-sumer/hifi") space and FACTS are very hard to find.

Believe me, I am not poo-pooing the DG/LC kit (whatever it's called - I just don't have any frame of reference with which to compare any of this silicon to each other). For now it looks like it is exactly what I need. (The code template is certainly more than 5 or 6 libs ;) ) ..

I have already compiled it, I just want a nice fresh start tomorrow when I eventually get the guts to flash it and start fiddling ;) Thanks for the help and patience.

[pinealservo]

Considering there's no DAC on that thing, all the emphasis on low-noise parts is kind of funny, but it's not entirely bogus when talking about the importance of good board design for high-speed digital signals and ensuring parts are run within spec. Having a bunch of extra RAM and unused MIPS is just wasteful, though. I haven't looked at exactly how the XMOS USB and SPDIF libraries spread their tasks across threads, but there's not really anything to be gained by running them on separate tiles if there's enough resources on one. Maybe they're making good use of the extra power, though... who knows? It's far from the most ridiculously overpriced or woo-filled ad copy for an audiophile gadget I've seen, though.

Anyway, good luck, and I hope you'll take the time to experiment with some of the code in the OpenAvnu repository as well. You could be the one to contribute a nice GUI frontend to the 1722.1 controller we've got. ;)