Trying to join the 2 devices inside ministreamer into one multi 4 channels virtual one.
Still doesn't work, but there is now something new:
Never seen an error message like this. Try to check if would work at 48khz?
Still doesn't work, but there is now something new:
Never seen an error message like this. Try to check if would work at 48khz?
Never seen an error message like this. Try to check if would work at 48khz?
No way, broken pipe in no time!
To tell the whole story, it also gets broken using only 2 output channels, as it ever and always happened when i tried to make an usb card work in duplex mode on an RPI : ALWAYS! The only exception has been using the Cirrus/Wolfson audio card which is not an usb card, of course not. That's why i practically gave up with multichannels dsp on an RPI.
In fact, that's why i am so amazed to see that i can make these things work using 3 usb cards, when using only one i never could... It is just unexplainable, but it works.
Thanks again Phofman to suggest using multiple usb devices!
No way, broken pipe in no time!
To tell the whole story, it also gets broken using only 2 output channels, as it ever and always happened when i tried to make an usb card work in duplex mode on an RPI : ALWAYS! The only exception has been using the Cirrus/Wolfson audio card which is not an usb card, of course not. That's why i practically gave up with multichannels dsp on an RPI.
In fact, that's why i am so amazed to see that i can make these things work using 3 usb cards, when using only one i never could... It is just unexplainable, but it works.
Thanks again Phofman to suggest using multiple usb devices!
Last edited:
Your device is locked to 48kHz and does not accept 44100. Often this happens when capturing at 48kHz is underway and the device cannot switch its output stage to a different samplerate. Or the soundcard offers several devices and one of them is already open at 48kHz.
You should be able to find out all capabilities including channels of your devices with aplay --dump-hw-params, such as
IMO altsets of your second device could be in /proc/asound/USB_CARD/stream1 instead of stream0. I have only single-device USB soundcards so cannot test for you.
You should be able to find out all capabilities including channels of your devices with aplay --dump-hw-params, such as
Code:
aplay --dump-hw-params -D hw:USB_CARD,0 -t raw - < /dev/zero
aplay --dump-hw-params -D hw:USB_CARD,1 -t raw - < /dev/zeroIMO altsets of your second device could be in /proc/asound/USB_CARD/stream1 instead of stream0. I have only single-device USB soundcards so cannot test for you.
I think this is a case for TDM (time division multiplexing)
although I am not sure at which level one implements it, the IC2 connection is shared, and it's based upon some metric of the clock and data capabilities such that you have enough time to interleave more channels of samples per frame...
see sections 3.1.2 and 4.5 in this pdf for one example...
http://www.ti.com/lit/an/snla221/snla221.pdf
although I am not sure at which level one implements it, the IC2 connection is shared, and it's based upon some metric of the clock and data capabilities such that you have enough time to interleave more channels of samples per frame...
see sections 3.1.2 and 4.5 in this pdf for one example...
http://www.ti.com/lit/an/snla221/snla221.pdf
so, you will want to check out TDM (time division multiplexing) that many DACs and ADCs offer as an i/o option
https://www.raspberrypi.org/forums/viewtopic.php?t=55799&p=854196
"
by mhelin » Mon Nov 25, 2013 11:59 am
For multi-channel output (or input) it would be easiest just to use TDM/DSP format for the D/A and the A/D converters. For an example of such device is the WM8768 DAC (Analog and Digital Processing ICs, Semiconductor Company, Cirrus Logic).
To generate TDM frame sync of I2S LRCK you for an example need to set the two LSB's in the last 32-bit sample of a frame and sample this data output using D-type flip flop (data to D input and LRCK to CK input, Q is the frame sync output). If you want be absolutely sure that the data output is valid at the raising edge of the LRCK just use another D-FF to sample the data out on rising bit clock first (maybe not necessary at all, I guess the data output is not changed until the next zero is output). The NL17SZ74 is a good one (fast enough) for FF chip (http://www.onsemi.com/PowerSolutions/pr ... d=NL17SZ74).
There are also many TDM/DSP compatible AD converters available, WM8786 (Analog and Digital Processing ICs, Semiconductor Company, Cirrus Logic) though being a stereo one, is one example.
You will also need an external MCLK, and if it's frequency must be bigger than bit clock's you need a divider circuit (same part is OK, but connect as divider, 24.567MHz into CK, /Q to D and Q is the 12.288 MHz output).
Posts: 109Joined: Wed Oct 17, 2012 7:18 pm "
https://www.raspberrypi.org/forums/viewtopic.php?t=55799&p=854196
"
by mhelin » Mon Nov 25, 2013 11:59 am
For multi-channel output (or input) it would be easiest just to use TDM/DSP format for the D/A and the A/D converters. For an example of such device is the WM8768 DAC (Analog and Digital Processing ICs, Semiconductor Company, Cirrus Logic).
To generate TDM frame sync of I2S LRCK you for an example need to set the two LSB's in the last 32-bit sample of a frame and sample this data output using D-type flip flop (data to D input and LRCK to CK input, Q is the frame sync output). If you want be absolutely sure that the data output is valid at the raising edge of the LRCK just use another D-FF to sample the data out on rising bit clock first (maybe not necessary at all, I guess the data output is not changed until the next zero is output). The NL17SZ74 is a good one (fast enough) for FF chip (http://www.onsemi.com/PowerSolutions/pr ... d=NL17SZ74).
There are also many TDM/DSP compatible AD converters available, WM8786 (Analog and Digital Processing ICs, Semiconductor Company, Cirrus Logic) though being a stereo one, is one example.
You will also need an external MCLK, and if it's frequency must be bigger than bit clock's you need a divider circuit (same part is OK, but connect as divider, 24.567MHz into CK, /Q to D and Q is the 12.288 MHz output).
Posts: 109Joined: Wed Oct 17, 2012 7:18 pm "
Ok.
Re: --dump-hw-params 😕
Re: stream1. Seems to make sense.
Now, i don't think there is any issue with miniStreamer. IMH and burnt out opinion, the only issue is with usb-audio on a RPI, and the issue is: CANT CAPTURE AND PLAYBACK AT SAME TIME with same USB card on an RPI!
I am quite sure that if i hook a second miniStreamer for capture and use the previous one for playback, it will then work.
Wrapping things up: One USB card on a RPI cannot do CAPTURE and PLAYBACK at the same time. BUT, one USB card can be used for CAPTURE and another one for PLAYBACK, provided sync issues are avoided, i.e., both work in adaptative mode... Hope this makes sense, and hopefully is usable...🙄
Re: --dump-hw-params 😕
Re: stream1. Seems to make sense.
Now, i don't think there is any issue with miniStreamer. IMH and burnt out opinion, the only issue is with usb-audio on a RPI, and the issue is: CANT CAPTURE AND PLAYBACK AT SAME TIME with same USB card on an RPI!
I am quite sure that if i hook a second miniStreamer for capture and use the previous one for playback, it will then work.
Wrapping things up: One USB card on a RPI cannot do CAPTURE and PLAYBACK at the same time. BUT, one USB card can be used for CAPTURE and another one for PLAYBACK, provided sync issues are avoided, i.e., both work in adaptative mode... Hope this makes sense, and hopefully is usable...🙄
Last edited:
--dump-hw-params - this parameter was added in 2012 git.alsa-project.org Git - alsa-utils.git/commit I happened to need that param, it was trivial. Your alsa-utils seem pretty old...
That stream1 clearly shows your device 1 supports only 48kHz. No wonders the combined device 0 + 1 also supports only 48kHz.
I would be surprised if RPI did not support simultaneous capture and playback over USB. IMO the problem is somewhere else...
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.
That stream1 clearly shows your device 1 supports only 48kHz. No wonders the combined device 0 + 1 also supports only 48kHz.
I would be surprised if RPI did not support simultaneous capture and playback over USB. IMO the problem is somewhere else...
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.
So maybe it seems that YOU, and apparently many others that swear that these things can be done on a RPI whithout having checked by themselves before if does work or not on a RPI, haven't tried by your self to do these things on an RPI ... I DID and can swear it has been a real pain in the ....!
And of course i have also tried to do the same things on a laptop with Ubuntu, and the problem is that it worked well on the laptop with Ubuntu but no longer worked when ported to the rpi...So maybe the problem is not me and my poor linux skills, simply something is wrong with usb audio on the RPI...
Nonetheless, thanks again for having helped me to float my boat...
Last edited:
I repeat: I now managed to make work what never work before.
I don't understand why either, just sugesting that usb audio is ... tricky on RPI, but there is a fact: WHAT NEVER WORKED BEFORE IS NOW WORKING! Aleluiaaaa....
And that is what rules for me...😎
Last edited:
Very good, do you have any idea what was changed?
Nevertheless, now you have made another step towards your working setup. I would suggest to modify the .asoundrc step by step while always testing the small changes.
Nevertheless, now you have made another step towards your working setup. I would suggest to modify the .asoundrc step by step while always testing the small changes.
Of course i don't!😀
My alsa knowledge is very limited indeed, and so i try to use it in the most elementary way through hw: only. Never used plughw nor weird customs builds in .asoundrc i don't understand. First time i use .asoundrc btw, just because i needed to build the multi device.
First thing i get reading my hw params, first can of worms: access ( MMAP_INTERLEAVED, or whatver....). What the hell is this about?🙁
It will be a long, long way...
Again, linux does not hide anything from you. As a result you have many options available.
Device hw:X provides direct access to the device. Therefore, it accepts only sample formats/samplerates/channel count directly supported by the device (i.e. output of streamX for USB, or --dump-hw-params for any soundcard).
Plughw:X (or plug:hw:X) is hw wrapped with alsa plug plugin which accepts any input parameters and converts automatically as needed to satisfy your soundcard. Therefore aplay -D hw:X your.wav will often fail with "Unsupported...", while plughw:X will accept and the aplay -v (verbose) param will tell you all the transformations the plug plugin has to apply before sending to your soundcard.
If you want to learn, just play with it a bit, it is simple. I do not know what you want to achieve, there may be easier ways using ready-made solutions.
Device hw:X provides direct access to the device. Therefore, it accepts only sample formats/samplerates/channel count directly supported by the device (i.e. output of streamX for USB, or --dump-hw-params for any soundcard).
Plughw:X (or plug:hw:X) is hw wrapped with alsa plug plugin which accepts any input parameters and converts automatically as needed to satisfy your soundcard. Therefore aplay -D hw:X your.wav will often fail with "Unsupported...", while plughw:X will accept and the aplay -v (verbose) param will tell you all the transformations the plug plugin has to apply before sending to your soundcard.
If you want to learn, just play with it a bit, it is simple. I do not know what you want to achieve, there may be easier ways using ready-made solutions.
Yes, that's why i prefer hw to plughw, though it gives extra work or requires extra attention. Don't think i'm wrong with this...
I just pretend to make brutefir run as flawlessly on a rpi as i get it running on an ubuntu laptop with same usb soundcards and same brutefir_configs.
Hence trying to understand why these things are so easy to get done on my laptop, and mysteriously half work or no longer work at all when ported to the RPI.
I am quite sure i am not alone with such problems, though if found interest for dsp with brutefir on rpi being apparently scarce among rpi users...
Last edited:
Well, something has to align the params to your card anyway. Be it a player which supports all the conversions (some do, some don't), or be it a universal plugin doing the work automatically. If you know what is going on, it really does not matter that much.
Only the plug plugin uses the rate plugin for samplerate conversion which can input/output only 16 bits (i.e. downsampling in case of 24 bit samples). The Envy24-based soundcards I use support all the usual sample rates automatically so I do not use the rate conversion at all.
As of your RPi - it is well known to have the USB port overloaded, using a SoC not designed for general-use computing. Many people report problems with USB devices, not only soundcards.
I personally prefer x86 thin clients to ARM boards. The used ones I buy cost about the same as RPi but due to being x86 are WAY easier to work with.
Agree. Just can't understand why some insist on using those limited arm boards ( Rpi, BBB, or else...) and then are ready to invest x10 or x20 more on a top of the pops state of the art dac affair, DSD capable, diy or comercial, and so on...
Personnally if were on something really ambitious, i would start spending a little more on something more reliable like a Nuc, and later would evaluate if it's worth or not buying an RME fireface UCX, for instance, or keep playing with the crappy isosychronous usb dacs i am trying to make work with an rpi...Simple question of balance and common sense, i think...😀
I have a great experience with FS Futros for about 20 EUR, they look like brand-new (some were brand new indeed, original packaging), no moving parts, PCI slot (newer have PCI-e), several USB ports (hooked to several USB controllers), native gigabit ethernet (no USB hook), functioning wake-on-lan for resuming from suspended-to-memory, etc.
E.g. S450, S550 (no connection with the seller 🙂 ) Fujitsu Futro S450-2 Thin Client AMD Sempron 200U 1GHz CPU 1GB RAM 2GB CF Card | eBay
Or HP 75XX for similar price.
It is not multicore, true, but the 64bit CPUs support extended instructions and may end up being faster than RPi.
E.g. S450, S550 (no connection with the seller 🙂 ) Fujitsu Futro S450-2 Thin Client AMD Sempron 200U 1GHz CPU 1GB RAM 2GB CF Card | eBay
Or HP 75XX for similar price.
It is not multicore, true, but the 64bit CPUs support extended instructions and may end up being faster than RPi.
Hi,
I follow you point about ARM boards, but how is it possible to "extract several I2S lines from x86 platforms ? Is the minidisp USB streamer (or ministreamer) the only option?
Following Aaronpeacok suggestions about I2S TDM, I discovered the beaglebone capabilities with I2S, and its (unique?) capability to drive at least 4 I2S. But it is the now less powerful fo the SBC.
So on one side the BBB with good I2S capabilies but low calculation power, and on the other side the x6 with USBstreamer.
Other cheap/versatile/software oriented options to consider for active amp / digital cross-over crossovers / I2S input digital amp ?
What I would like to achieve is a very simple set-up with:
- SBC (or x86) with I2C and several I2S capabilities
- driving 2 or 3 https://polyvection.com/shop/plainamp/ style amps (ideally STA326)
Best regards,
JMF
I follow you point about ARM boards, but how is it possible to "extract several I2S lines from x86 platforms ? Is the minidisp USB streamer (or ministreamer) the only option?
Following Aaronpeacok suggestions about I2S TDM, I discovered the beaglebone capabilities with I2S, and its (unique?) capability to drive at least 4 I2S. But it is the now less powerful fo the SBC.
So on one side the BBB with good I2S capabilies but low calculation power, and on the other side the x6 with USBstreamer.
Other cheap/versatile/software oriented options to consider for active amp / digital cross-over crossovers / I2S input digital amp ?
What I would like to achieve is a very simple set-up with:
- SBC (or x86) with I2C and several I2S capabilities
- driving 2 or 3 https://polyvection.com/shop/plainamp/ style amps (ideally STA326)
Best regards,
JMF
Multi channel high end pro sound cards like this sound wonderfull with proper Win or Mac computers and software like JRiver as both music server and DSP machine for DRC and/or XOVER. But no problem if some will find more challenging using a BBB or an RPI with some weird piece of soft and hardware to try and reinvent the wheel on a cheaper ( or not so cheaper...) way...😉
RME: Fireface UCX
Last edited:
E.g. M-Audio Delta 1010 has all the I2S lines of the VIA1712 (Envy24) controller available at the DB25 connector. 8 channels + SPDIF.
This controller has complete support in linux, I find it one of the best ever. No complicated DSP, but full 192/24 support, 10 channels out, separate crystals for 44.1/48kHz families, complete documentation available.
In fact I have an Envy24 PCI card in my internet radio built from Futro S400 with PCI riser inside. Since Delta1010 very likely does not need the -12V not available on the futros PCI slot (since it uses only digital signals), this combination could fit perfectly. I do not know about CPU power for all the filtering, never tested. The newer Futros (450, 550) have the PCI slot too, but unfortunately only half-sized cards fit. Of course one can always open the top cover and insert full-size card without the angle riser...
IMO getting mutichannel I2S from x86 is easier than from ARM.
- Status
- Not open for further replies.