Multi channel audio and I2S ?

[JMF11]

Thank you phofman and gdo for sharing,

The Envy24 and M-Audio Delta 1010 looks promising. I'm trying to think about all questions before jumping, as having a correct architecture and good basements helps to spend time to achieve good performance instead of fighting against stupid things, or things that only derive from too quickly made bad choices. We can find some second hand ones here for 100-150€.

My main concern is to find an acceptable thin client, fan less, that would accept the board, and fit in our living room.

I had considerd a budget about 100€ for the "source" (having in mind the not suitable R Pi).

I also have to do my homework to understand this question of crystals for 44.1/48kHz families. I thought that the R Pi could play "anything" without additiona expensive clock. But it seems that there is something important here (I also see that this appears for the beaglebone + cronus).

Best regards,

JM

 

[GDO]

I also have to do my homework to understand this question of crystals for 44.1/48kHz families. I thought that the R Pi could play "anything" without additiona expensive clock. But it seems that there is something important here (I also see that this appears for the beaglebone + cronus).

You mean the "need" for 2 different clocks running at a multiple frequecy of each set of sampling freqs ( 44.1/88.2/etc...48/96/192...) ?

Imho, it is the kind of "delicatessen" most people can live without..😛

Btw, it seems that BBB is a more suitable platform that RPI for multichannel I2S. I insist on "seems", because this is reported by people from the "bit perfect" squad more on high-end dac stuff than dsp, xovers etc... Haven't read anything for the moment about i2S ADCs on BBB. What d'ya need that for, ripping you CDs?😀

 

[JMF11]

There is this attempt of software crossover thing on BBB:
http://www.diyaudio.com/forums/twisted-pear/277564-ladspa-filters-digital-crossovers-bbb.html

The Texas chip has a pretty cool McASP feature for audio digital input/output, which is far above (on the datasheet) the other SBC. But not sure that the driver implementation in a standard feature of the kernels. The effort seems to rely on one person.

What worries me a bit is:
- the McASP driver may require manual propagation from distribution releases to new ones and the community is small,
- why people don't seem to use this feature "plain vanilla", but feel the need (with some good reasons I'm sure) to add 160$ Cronus/Hermes/Clocks on top of the 50$ board.

JMF

 

[GDO]

Same happens with the Cirrus/Wolfson card for the RPI. The product is great, but the lack of support and driver integration to the standard raspbian makes it practically unusable, unless you have the skills to build the drivers by yourself. Fortunately i could download a custom distro with the drivers included. Apt-get upgrade forbidden though...

 

[phofman]

You mean the "need" for 2 different clocks running at a multiple frequecy of each set of sampling freqs ( 44.1/88.2/etc...48/96/192...) ?

Imho, it is the kind of "delicatessen" most people can live without..😛

It is simply easier if the sound controller does not need PPL to generate the masterclock, just switching the crystal input. Is the difference audible? I do not know, I never did any DBT in this respect (this one would be rather complicated as I do not think there is a soundcard offering PLL as well as dual crystals to switch between). But I doubt anyone could tell a difference.

The problems with non-standard drivers for the ARM boards - since ARM has no reliable detection like PCI detection on x86, configuration of peripherals on various ARMs is PITA. No wonders the Wolfson I2S DAC drivers have not made it to the stock kernel yet, it is a very specific piece of HW and cannot be detected automatically.

Again, another reason for me to use the small inexpensive x86 machines with countless soundcards available and always supported by stock kernel 🙂

 

[GDO]

I never did any DBT in this respect (this one would be rather complicated as I do not think there is a soundcard offering PLL as well as dual crystals to switch between)

I suggest DBDDT instead.

 

[phofman]

I had considerd a budget about 100€ for the "source"

OK, let's see:

FS Futro S400 (AMD 1GHz), 512MB RAM (should be enough), flash 512MB (not enough)
Fujitsu Siemens Futro S400 AMD 1Ghz 512MB DDR 512MB FLASH ohne Netzteil | eBay

It already has the PCI riser installed

14 EUR + 15 EUR Shipping Europe

Power adapter - any 12V/2A adapter will do, typically some available at home - 0 EUR

new 2GB CF card - 10 EUR

M-Audio Revo 7.1 Avid Technology M Audio Revolution PCI Revolution 7 1 Sound Card | eBay - 42 USD i.e. 37 EUR

8 channels, I2S would have to be soldered to the traces, rather simple. This is the cheapest Envy24 7.1 card I found on Ebay. Actually, any Envy24-based card would do, but would require modifying the alsa driver. Whereas a native 7.1 card does not need any driver tweaks - just use the 8channel alsa device.

Total 29 EUR PC + 10 EUR CF + 37 EUR soundcard = 76 EUR

There are doubtlessly countless other variants.

I would use the remaining money for some good I2S buffer in differential mode (LVDS?). IMO the I2S transfer to the amp is the major caveat of this solution (regular I2S is very sensitive to longer leads). Actually, I would prefer using a PCI extender cable PCI 32 Bit 33Hz Riser Card-Ergänzung-Verlängerungs-Flexkabel-Adapter Ribbon 19CM | eBay , putting the soundcard into the amplifier enclosure. 15 cm is just about taking the PCI from the PC case. Perhaps two cables could be chained, but the 33MHz clock would have to be tested.

 

[amix]

My understanding is that I2S can only address 2 audio channels

You may be interested what Russ White has done in the TwistedPear forum, here at diyaudio. Especially the threads:

Building an open embedded audio applicance

and

Hermes-BBB/Botic cape for BeagleBone Black

may be of interest. However, some of the information is scattered over other threads. Russ' TwistedPear Audio is a manufacturer of DIY kits, especially for DACs, but also control etc. AFAIR I2S is what they used when connecting his Buffalo-III DAC using the ESS Sabre chip, which is an 8 channel DAC.

 

[phofman]

Actually, the PCI cable would allow using the more powerful Futro S550 which are for the same price with 1GB DDR2, 1-2 GB CF, basically brand new.

 

[GDO]

I am always surprised to see how some are extremely ambitious with 2 channels dacs specs, and still accept much less ambitious passive xover designs on the speaker side.

Still consider that speakers are the weakest link in the chain, and clocks always good enough, but...

 

[JMF11]

Ok, a lot of options are open, all very cost effective.

Since last week, I asked myself a lot of questions and you helped address many of thems. I start to see more clear. However, I have to stop try to run all businesses at the same time, ans must focus. So my work plan if to go through successive stages:
- build my LXmini, that won't use passive xover,
- develop the xover on a Linux laptop, with 2 USB plugs, to drive 2 FX-Audio D802 (through USB)
- once the setup will work as expected, port the linux config in a more compact set-up (x86 or ARM) with I2S capability and digita filtering capability
- ultimate stage, try to connect Full Digita Amp directly through I2S to the compact set-up, and have an "accurate" clock.

I have some work in front of me, but I have a plan.

Now it is time for remote vacations. This project will resume in 2 weeks.

Thanks a lot for your help !!!!

JMF

 

[aaronpeacock]

just another random suggestion, as i realize i'm not following this discussion closely enough...

i have a gut reaction against USB due to
1) its a high level stack to bit-bang without an OS
2) clock issues, especially trying to derive a bitclock from it.
3) why USB is "universal" when a basic UART is way more "universal"?

one should be able to bit-bang TDM with I2S format streams interleaved multiple channels per frame (and drive a TDM capable multi-codec via this software bit-banged TDM) using any fast microcontroller or CPU.
One could also consider a Zynq capable board like the parallella or any FPGA fabric to implement a TDM engine.
it's a low-level operation involving recieving buffers, a bit clock, as explained in the links. not the hardest protocol to bit-bang... a lot easier than USB...

i guess you are probably not interested in going below linux but if you did, you could basically present your bit-banged TDM as a driver and then use it via it's API...

anyway digressing a lot here... good luck!

 

[Loafmeat]

You can see my setup here:

diyAudio server HTTPS page

HIFI-FORUM » Do it yourself » Lautsprecher » Aktive Frequenzweiche per Standard Software mit GUI

Sorry it is in German

You have
4 x 2 crossover
many parametic equalizer
limiter
....
much more

HDMI 8 Channel output
8 Channel analog output

For activating for example 2, 3 or 4 way loudspeaker

With Standard PC and free Software.





Sadly the odroid c2 is sold out at the Moment

ODROID | Hardkernel

with HIFI Shield I2s extension

I will give it a try if it is availabe again.
odroid c2 has hdmi 2.0
I will check how many Audio channels will be available






Regards
Guenter

 

[francolargo]

Try capturing using arecord (arecord -v -D plughw:2 - > /dev/null ) while playing back at the same time (aplay -v -D plughw:2,0 -t raw - < /dev/zero ). IMO it will work, the problem is very likely in your input/output parameters. Also, I still do not understand how the SPDIF input clock and USB adaptive clock are matched in ministreamer.

I am delighted to come across this thread! I have a small contribution and then a problem to discuss with some of you. First, what is working for me:

I am using a Beaglebone Black with all of the clock-switching stuff from TPA. With help from Pavel (@phofman) I got LADSPA filters running well in ALSA to perform an active speaker crossover. The final part of my project is to also use this ALSA crossover to process audio from video feeds and do it with minimal latency.

USB input to the BBB worked without any problem, and I have been using a Roland UA-25EX to convert Toslink to USB. [This is trouble-free but not my preferred hardware - more about that below...] I tried three solutions in Linux to pass data from record to playback:

ecasound -z:mixmode,sum -x -d -b:4096 -a:in -i:alsahw,1,0 -o:loop,1 -a:out -i:loop,1 -a:out -o:alsahw,0,0
or
ecasound -z:mixmode,sum -x -d -B:rt -a:in -i:alsahw,1,0 -o:loop,1 -a:out -i:loop,1 -a:out -o:alsahw,0,0

Ecasound seems to only output to hardware channels - I can't direct output to ALSA plugins. So any filtering would need to be programmed into ecasound itself. That's easy enough, but the latency of the ecasound loop is impossible for video.

arecord -c 2 -t raw -f dat -r 48000 -D hw:1,0 | aplay -c 2 -t raw -f dat -r 48000 -D <your preferred ALSA plugin>

You can add the -B option to specify a buffer time in microseconds. This works well and latency is fairly small, but the lowest latency is achieved using SoX:

 with defaults:
sox -c 2 -t alsa hw:1,0 -t alsa <your preferred ALSA plugin or hw>

Tuned for better performance:
nice -n -20 sox --buffer 1024 -c 2 -t alsa hw:1,0 -t alsa <your preferred ALSA plugin or hw>

Tuned for maximum performance:
chrt -f 45 sox --buffer 512  -c 2 -t alsa hw:1,0 -t alsa <your preferred ALSA plugin or hw>

This last version elevates the run priority of SoX to just below the IRQ processes, which makes it difficult to handle except with keyboard-level interrupts. I have a python script that can kill it. With this last setup, the flash from a gun and the 'bang' it produces seem to happen at the same time. 🙂

I hope this might help, at least as a departure for your own tests.

 

[francolargo]

Some of you are using the miniStreamer. I would like to use it too (built into the chassis with the BBB) but it is not working with my BBB setup.

First, is it designed for 'consumer-level' (0.5 volts peak-to-peak) or 'TTL-level' (2-5 volts PP) SPDIF? I tried both. Also, I'm powering it from a linear supply at 5.25v.

Second, the miniStreamer is fully recognized in ALSA, and I can make recordings using 'arecord'. However, the contents of the recordings is nothing but silence. For starters, I just need a signal in the record stream. 🙁

Any and all suggestions on a diagnosis/debug path will be much appreciated!

With thanks in advance,

Frank

 

[GDO]

Some of you are using the miniStreamer. I would like to use it too (built into the chassis with the BBB) but it is not working with my BBB setup.

First, is it designed for 'consumer-level' (0.5 volts peak-to-peak) or 'TTL-level' (2-5 volts PP) SPDIF? I tried both. Also, I'm powering it from a linear supply at 5.25v.

Second, the miniStreamer is fully recognized in ALSA, and I can make recordings using 'arecord'. However, the contents of the recordings is nothing but silence. For starters, I just need a signal in the record stream. :

Ministreamer is based on TE72022 usb chip. From the manufacturer datasheet:

Built in IEC60958 professional S/PDIF TX & RX, AES/EBU supported

TE7022L - Galaxy Far East Corp.

So i understand a wide range of voltages is admited.

Ministreamer can be used in master mode but only through i2s, not capturing spdif. In such case it does need to be connected to the spdif out of a running source ( simply on, but not necessarily playing) to start running.

 

[GDO]

I have also been testing new setups which have been working fine for me:

1º Cirrus Logic audio card as capturing device ( analog & spif both tested) and multiple usb cards as playing devices. Tested on B+ and 2 rpi models with the allpiversions image from CLAC running brutefir with a 2 ways xover config. The B+ is pushed to its limits but on PI2 the cpu load is low.

2º Famous elcheapo 7.1 usb card (CM6206 inside) as playing device and another usb card based on the TE7022 chip, ESI model U24XL ( similar to minidsp but with analog inputs and limited to 48khz) on a RPI3 + Jessie running brutefir with a 4ways xover config. Very stable operation and clean sound without any clicks nor drop outs. Interestingly, if i use the line input of the 7.1 card instead of the dedicated to capture other card, the sound is rubbish.

Using a dedicated card for capturing purposes seems to be mandatory in my experience, i2S and USB too though not any usb device will necessarily work.

 

[francolargo]

Ministreamer can be used in master mode but only through i2s, not capturing spdif. In such case it does need to be connected to the spdif out of a running source ( simply on, but not necessarily playing) to start running.

Thanks for the info @GDO!

I notice that I can only run 'arecord' with '-D plughw:miniStreamer,0' when miniStreamer is in master mode. Otherwise I get: "arecord: pcm_read:2031: read error: Input/output error".

So let me be sure I understand:

A) miniStreamer only sends out USB packets in master mode?

B) miniStreamer can never capture SPDIF for conversion to USB packets, but external I2S can be converted to USB and exported to the BBB? 🙁

C) In order for that conversion to be initiated, an I2S source must be present when miniStreamer (in master mode) is powered up?

Correct or no?

If this is all correct it would not be to my liking. I do have a Wolfson 8804 board that makes I2S from SPDIF. The 8804 can run as clock master or clock slave. But it sounds like I would need to power-up the miniStreamer after I admit a new Toslink stream to the system. A deal breaker for now...

My other gripe about miniStreamer is that it injects a small amount of 60Hz hum via the USB, even though it is 'floating' with respect to chassis and power ground. ...wouldn't look forward to ironing that out...

Does anybody know if the XMOS-based product from miniDSP will go straight from Toslink input to USB output?

TIA,

Frank

 

[GDO]

Imho, it simply might be that your ministreamer is set to I2S instead of SPDIF as is per default, if i remenber well...

Check this with: amixer -c X contents

numid=8,iface=MIXER,name='PCM Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Line'
; Item #1 'IEC958 In'
: values=0

And if "Line" appears to be the default ( as above) change it to SPDIF (IEC958) by:

amixer -c X cset numid=8 1

so that you get as content:

numid=8,iface=MIXER,name='PCM Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=2
; Item #0 'Line'
; Item #1 'IEC958 In'
: values=1

Btw, i am using ministreamer connected to spdif out of a CD player and the CD player must be on, though not playing at all, to avoid any error.

 

[francolargo]

Imho, it simply might be that your ministreamer is set to I2S instead of SPDIF as is per default, if i remenber well...

snip

Btw, i am using ministreamer connected to spdif out of a CD player and the CD player must be on, though not playing at all, to avoid any error.

This worked!!! 😀😀😀 Now the recording stream has content and I can work out the specifics for my various operating modes. (I use I2C to swap between a pair of Toslink inputs.)

Thanks for getting me rolling!

Also, I don't hear that 60Hz hum through speakers, only headphones - so I think the source will be easy to hunt down. It's not the miniStreamer per se.

Cheers!

Frank