@Stretchie
You may be experiencing ALSA buffer Xruns. You should be able to get more info from ecaound about that by running ecasound with the -ddd option (add debug info, the more "d"s you use the more there is). This will spit out a lot of output, so just pipe that into a file and kill the process after you hear a glitch. Then go back and look through the output info.
Did you do any kernel mods and rebuild the kernel or does the system have the stock kernel. Which kernel is it?
You may be experiencing ALSA buffer Xruns. You should be able to get more info from ecaound about that by running ecasound with the -ddd option (add debug info, the more "d"s you use the more there is). This will spit out a lot of output, so just pipe that into a file and kill the process after you hear a glitch. Then go back and look through the output info.
Did you do any kernel mods and rebuild the kernel or does the system have the stock kernel. Which kernel is it?
Thank you Charlie!
Do you mean this:
Kernel is rebuild, version 5.4.65-v7
Thanks!
Do you mean this:
Code:
i@raspberrypi:~ $ ecasound -ddd
**************************************************************************
* ecasound v2.9.1 (C) 1997-2014 Kai Vehmanen and others
**************************************************************************
(eca-session) Set debug level to: 511
(eca-session) Session created
(resource-file) Loading file /usr/share/ecasound/ecasoundrc.
(resource-file) Loading file /home/pi/.ecasound/ecasoundrc.
(audioio-db-server) constructor
(resource-file) Loading file /usr/share/ecasound/ecasoundrc.
(resource-file) Loading file /home/pi/.ecasound/ecasoundrc.
(eca-chainsetup) Using hardcoded defaults for "default-audio-format".
(eca-chainsetup-parser) Interpreting object option "-f:s16_le,2,44100,i".
(eca-chainsetup-parser) Changed active format to
... (bits/channels/srate/interleave): s16_le/2/44100/i
(eca-chainsetup) sample rate change, chainsetup untitled-chainsetup to rate
... 44100.
(eca-chainsetup-parser) Interpreting object option "-z:mixmode,avg".
(eca-static-object-maps) register_chain_operator_objects()
(samplebuffer) Buffer created, channels: 0, length-samples: 0.
(eca-object-map) match (1): eS to regexp ^eS$
(eca-object-map) match (1): ea to regexp ^ea$
(eca-object-map) match (1): eadb to regexp ^eadb$
(eca-object-map) match (1): eac to regexp ^eac$
(eca-object-map) match (1): eal to regexp ^eal$
(eca-object-map) match (1): eaw to regexp ^eaw$
(eca-object-map) match (1): ec to regexp ^ec$
(eca-object-map) match (1): eca to regexp ^eca$
(eca-object-map) match (1): eemb to regexp ^eemb$
(eca-object-map) match (1): eemp to regexp ^eemp$
(eca-object-map) match (1): eemt to regexp ^eemt$
(eca-object-map) match (1): ef1 to regexp ^ef1$
(eca-object-map) match (1): ef3 to regexp ^ef3$
(eca-object-map) match (1): ef4 to regexp ^ef4$
(eca-object-map) match (1): efa to regexp ^efa$
(eca-object-map) match (1): efb to regexp ^efb$
(eca-object-map) match (1): efc to regexp ^efc$
(eca-object-map) match (1): efh to regexp ^efh$
(eca-object-map) match (1): efi to regexp ^efi$
(eca-object-map) match (1): efl to regexp ^efl$
(eca-object-map) match (1): efr to regexp ^efr$
(eca-object-map) match (1): efs to regexp ^efs$
(eca-object-map) match (1): ei to regexp ^ei$
(eca-object-map) match (1): enm to regexp ^enm$
(eca-object-map) match (1): epp to regexp ^epp$
(samplebuffer) Buffer created, channels: 0, length-samples: 0.
(eca-object-map) match (1): chorder to regexp ^chorder$
(eca-object-map) match (1): chcopy to regexp ^chcopy$
(eca-object-map) match (1): erc to regexp ^erc$
(eca-object-map) match (1): chmove to regexp ^chmove$
(eca-object-map) match (1): chmute to regexp ^chmute$
(eca-object-map) match (1): erm to regexp ^erm$
(eca-object-map) match (1): chmix to regexp ^chmix$
(eca-object-map) match (1): etc to regexp ^etc$
(eca-object-map) match (1): etd to regexp ^etd$
(eca-object-map) match (1): ete to regexp ^ete$
(eca-object-map) match (1): etf to regexp ^etf$
(eca-object-map) match (1): etl to regexp ^etl$
(eca-object-map) match (1): etm to regexp ^etm$
(eca-object-map) match (1): etp to regexp ^etp$
(eca-object-map) match (1): etr to regexp ^etr$
(eca-object-map) match (1): ev to regexp ^ev$
(eca-object-map) match (1): evp to regexp ^evp$
(eca-object-map) match (1): ezf to regexp ^ezf$
(eca-object-map) match (1): ezx to regexp ^ezx$
(eca-object-map) match (1): gc to regexp ^gc$
(eca-object-map) match (1): ge to regexp ^ge$
(eca-object-map) match (1): gm to regexp ^gm$
(eca-static-object-maps) register_controller_objects()
(osc-gen) setting param 1 (freq) => 0.00
(osc-gen) setting param 2 (mode) => 0.00
(osc-gen) setting param 1 (freq) => 0.00
(osc-gen) setting param 2 (mode) => 0.00
(eca-object-map) match (1): kf to regexp ^kf$
(osc-gen) setting param 1 (freq) => 0.00
(osc-gen) setting param 2 (mode) => 0.00
(eca-object-map) match (1): kog to regexp ^kog$
(eca-object-map) match (1): kl to regexp ^kl$
(eca-object-map) match (1): kl2 to regexp ^kl2$
(eca-object-map) match (1): klg to regexp ^klg$
(eca-object-map) match (1): km to regexp ^km$
(eca-object-map) match (1): kos to regexp ^kos$
(samplebuffer) Buffer created, channels: 0, length-samples: 0.
(eca-object-map) match (1): ksv to regexp ^ksv$
(eca-chainsetup) Using hardcoded defaults for "bmode-defaults-nonrt".
(eca-chainsetup) Using hardcoded defaults for "bmode-defaults-rt".
(eca-chainsetup) Using hardcoded defaults for "bmode-defaults-rtlowlatency".
(eca-chainsetup-parser) Interpreting global option
... "-G:jack,ecasound,notransport".
(eca-chain) constructor: CHAIN
(eca-chainsetup) Chain "default" created.
(eca-chainsetup-parser) Interpreting object option
... "-G:jack,ecasound,notransport".
(eca-chainsetup) Set manager "jack" option string to "ecasound,notransport".
(eca-chainsetup) Chainsetup "untitled-chainsetup"
(eca-session) NOTE: Unable to create a valid chainsetup from the
... command-line arguments.
(eca-control) ECA_CONTROL constructor
(eca-chainsetup) Unable to connect: No inputs in the current chainsetup.
... (1.1-NO-INPUTS)
Warning: type DBC_NEVER_REACHED soft-assert '(null)' failed at
-> eca-control-main.cpp:63 [static std::__cxx11::string ECA_CONTROL_MAIN::return_value_to_string(const eci_return_value*, int)]
(eca-control) ECA_CONTROL destructor
(eca-session) ECA_SESSION destructor-in
(eca-chainsetup) ECA_CHAINSETUP destructor-in
(eca-chainsetup) Deleting chain "default".
(eca-chain) CHAIN destructor!
(audioio-db-server) destructor
(audioio-db-server) destructor-out
(eca-chainsetup) ECA_CHAINSETUP destructor-out
(eca-session) ECA_SESSION destructor-outThanks!
Yes, that's the debug output from ecasound. I see you were running the 2 channel version. Do that again for the 6 channels version. To redirect the output to a file instead of the screen, append the command with:
> output.txt
This will create a new file as needed and will overwrite if the file exists.
There will be a lot of debug output. I can't recall exactly what the Xrun info will look like. You will have to do some searching. The beginning part will be all about setting up and beginning the chainset. Then there will only be error messages I think, but I haven't looked at this kind of output in a long time so I am not totally sure.
When I first developed the mod to the pcm kernel file I had to experiment a bit with these settings:
Code:
.buffer_bytes_max = 256 * 1024,
.period_bytes_min = 1 * 1024,
.period_bytes_max = 256 * 1024,
.periods_min = 1,
.periods_max = 256,The Pi 4 SOC hardware and Raspbian OS are different these days from when I developed the mod originally, and others are likely more familiar with the situation in the kernel at the current time.
Got this:
NOTE: Real-time configuration, but insufficient privileges to utilize real-time scheduling (SCHED_FIFO). With small buffersizes, this may cause audible glitches during processing.
NOTE: Real-time configuration, but insufficient privileges to utilize real-time scheduling (SCHED_FIFO). With small buffersizes, this may cause audible glitches during processing.
Code:
**************************************************************************
*^[[1m ecasound v2.9.1 (C) 1997-2014 Kai Vehmanen and others ^[(B^[[m
**************************************************************************
(eca-chainsetup-parser) Looping enabled. Length of input objects will be
... used to set the loop point.
(eca-chainsetup-parser) Invalid buffersize given; using default value.
(eca-chainsetup) Chainsetup "untitled-chainsetup"
(eca-chainsetup) NOTE: Real-time configuration, but insufficient privileges
... to utilize real-time scheduling (SCHED_FIFO). With small buffersizes,
... this may cause audible glitches during processing.
(eca-chainsetup) "rt" buffering mode selected.
(eca-chainsetup) NOTE: using existing audio parameters -f:s16_le,6,44100
... for object 'chan_labels_6.wav' (tried to open with -f:s16_le,2,44100).
(eca-chainsetup) Opened input "chan_labels_6.wav", mode "read". Format:
... s16_le, channels 6, srate 44100, interleaved (locked params).
(eca-chainsetup) Opened output "alsa", mode "write". Format: s16_le,
... channels 6, srate 44100, interleaved.
(eca-chainsetup) Setting loop point to 5.81.
- [ ^[[1mConnected chainsetup: "untitled-chainsetup"^[(B^[[m ] ----------------$
- [ ^[[1mController/Starting batch processing^[(B^[[m ] -----------------------$
- [ ^[[1mEngine - Driver start^[(B^[[m ] --------------------------------------$
- [ ^[[1mController/Batch processing finished (0)^[(B^[[m ] -------------------$
- [ ^[[1mEngine exiting^[(B^[[m ] ---------------------------------------------$
(eca-control-objects) Disconnecting chainsetup: "untitled-chainsetup".The -B:rt option just sets some ecasound parameters to particular values. There is no need to set up higher priority for the application in the OS or use the "-r:sched_priority" option unless you are trying for very low latency processing.
Stretchie: your user is not configured/allowed to use the realtime scheduling (as the debug message suggests), but all these realtime params just cut the buffer sizes (which are OK for realtime scheduling). But you need to set them as large as possible to minimize the chances of buffer under/overruns (xruns in alsa speak).
Are you sure that hw:0,0 is the HDMI output? It's not typically device 0 on the card. You listed that for the 3-way configuration in post #120. You can check this by typing
Code:
aplay -lThe output will probably show the HDMI device as 1 or 3, possibly both, but probably not device zero.
Once you figure out which device is for the HDMI output, use that in place of the "?" in this command and post the output:
Code:
aplay -v -D hw:0,? -c 8 -f S16_LE -r 48000 --dump-hw-params /dev/zeroYou can compare the output you get to the output posted in post 12 of this thread.
Yes, it is:
Code:
pi@raspberrypi:~ $ aplay -v -D hw:0,0 -c 8 -f S16_LE -r 48000 --dump-hw-params /dev/zero
Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 8
HW Params of device "hw:0,0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S24_3LE
SUBFORMAT: STD
SAMPLE_BITS: [16 24]
FRAME_BITS: [32 192]
CHANNELS: [2 8]
RATE: [44100 192000]
PERIOD_TIME: [10000 743039)
PERIOD_SIZE: [441 32768]
PERIOD_BYTES: [1776 262144]
PERIODS: [1 75)
BUFFER_TIME: (2296 743039)
BUFFER_SIZE: [441 32768]
BUFFER_BYTES: [1764 131072]
TICK_TIME: ALL
--------------------
Hardware PCM card 0 'bcm2835 HDMI 1' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 8
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 8192
period_size : 2048
period_time : 42666
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 2048
period_event : 0
start_threshold : 8192
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0This device numbering is result of the patches which introduce the separate headphones, HDMI0, and HDMI1 cards, configured by the kernel module parameters enable_headphones, enable_hdmi0/1, unlike the other single-card format with multiple devices enabled by the param enable_compat_alsa. IMO the code is buggy for certain use cases, but it works OK for general usage and I have not had a need for the HDMI devices yet to make, send, and especially advocate a patch.
Stretchie: You really may want to try running your chain with larger buffers. That is the most common fix for glitches, if there are no real technical problems (the most common of which recently being ignored implicit feedback in USB-audio).
Stretchie: You really may want to try running your chain with larger buffers. That is the most common fix for glitches, if there are no real technical problems (the most common of which recently being ignored implicit feedback in USB-audio).
Hi everyone, on the last Black Friday I purchased a Rpi 3B to drive my (3-ways) Canton GLE 70s using an (old) Yamaha RX-V663 as DAC/multiamp.
Some questions:
Thanks in advance to anyone that can/will help.
Some questions:
- In the latest Rpi OS press release they claim From this release onwards, we are switching Raspberry Pi OS to use the PulseAudio sound server: does this effect our usage too ?
- The Yamaha HT amp supports up to 192000Hz sample rates, but I would love to (up or down) resample at the maximum "compatible" resolution respect to the source (eg. 44100/352800 -> 176400, 48000/384000 -> 192000): how to achieve this automatically ?
- Last but not least, how to configure Rpi in order to "manage" (= convert to PCM ?) DSD streams ?
Thanks in advance to anyone that can/will help.
@forart.eu - I'm pretty new to this too, so maybe I'll say something silly. But here goes...
1. We will have to see if this has any drawbacks... I think it's unlikely, since we send audio to ALSA directly.
2. So... this whole topic is about using an add-on board as a multi-channel DAC. If I understand this question properly, I think it belongs in another topic.
3. Again, this is a different scenario.
1. We will have to see if this has any drawbacks... I think it's unlikely, since we send audio to ALSA directly.
2. So... this whole topic is about using an add-on board as a multi-channel DAC. If I understand this question properly, I think it belongs in another topic.
3. Again, this is a different scenario.
I needed a couple of extra X6000s but couldn't find them anywhere. So at the suggestion of the vendor who supplied my cards I wrote to Suptronics who have advised me that a Pi4 compatible version of the X6000 card will be available shortly, perhaps as soon as May. Let's keep our fingers crossed.
Thanks for posting about that. When the Pi4 compatible HAT is finally available, can you post about it here?
The only downside is that the HAT sits close to the Pi itself, which means you cannot heatsink the Pi's SOC. It's the same with the 3B+, so dont' expect to be pushing the CPU to high loads. An IIR crossover is not a high load, even with 8 channels but 8 channels of FIR crossovers might be.
The only downside is that the HAT sits close to the Pi itself, which means you cannot heatsink the Pi's SOC. It's the same with the 3B+, so dont' expect to be pushing the CPU to high loads. An IIR crossover is not a high load, even with 8 channels but 8 channels of FIR crossovers might be.
