DarpMalone: Very well, thanks.
The aplay -l output shows you have the HDMI devices available.
aplay --dump-hw-params shows params of your analog output (both one-channel and two-channel configs are available). To check what channels and sample size are available for your HDMI device, run it with -D hw:0,1 or hw:0,2
Your PA indeed has only one sink available. That means the remaining are either disabled, or being used, or some other reason.
Please post output of pacmd list-cards to show what PA sees.
The aplay -l output shows you have the HDMI devices available.
aplay --dump-hw-params shows params of your analog output (both one-channel and two-channel configs are available). To check what channels and sample size are available for your HDMI device, run it with -D hw:0,1 or hw:0,2
Your PA indeed has only one sink available. That means the remaining are either disabled, or being used, or some other reason.
Please post output of pacmd list-cards to show what PA sees.
Funny coincidence is that I am in the middle of reading The Cathedral and the Bazaar, that book about open source development. I studied to be a scientist, but found fundamental research a bit lonely. I became sort of a social worker instead. I have always taken on additional roles, explored different methods, studied different aspects of society, to see if I could find a new approach to helping someone. My motivation seemed to be curiosity and personal satisfaction, but there were certain roles and projects I would *not* get involved with. I did not understand why. I turned to open source to see how software guys get motivated or not.
It is very enlightening. There are many different reasons and I am not going to act like I know Jürgen's. There is always a pay-off, always a benefit (or expected/intended). This may be charity, it may also be like a business card in code, or to develop something more quickly by letting others find bugs and feed the conceptual framework.
Discouraging codeless contributors may work against Jürgen's intended benefit.
Just saying.
I know what open source is about, I have run a couple of similar projects myself.
Budget is a false argument if it comes to project management and making priorities. Free/open source or not is totally irrelevant.
To put it into simple words, it basically just takes more time for a free project to get the same result. Nevertheless it doesn't have anything to do product itself but only when you do what, when and why.
Since even a piece of software has a lot more than just plain coding (fundamental math, user interface, practical implementation and much more) it's wise to discuss every aspect of it. (which is in my opinion also a technical aspect)
Fyi, the features I am requesting aren't really my personal suggestions, but basic fundamental blocks to make a product that people actually want to use.
I already said before that I can understand that Jürgen doesn't want to program two whole new apps for Android and iOS by himself, but that doesn't mean people can already discuss possibilities?
Generally a top-to-bottom approach works best here. So first come up with the most ideal product with all bells and whistles and then bit-by-bit cut off features until you have an optimum that is still doable in a certain amount of time and work.
Anyhow, by no means I have the intention to discourage anyone. I guess just asking for some mutual understanding and respect.
Because basically I am just echoing the voice of many frustrated audio enthusiasts here (a lot of them contact me on a regular basis to ask for advice and explanation), who simply don't have the skills, knowledge or time to troubleshoot all the quirks all the time.
I think it's obvious that in the end developers can do whatever they want with these frustrations, I am just saying not to underestimate it.
The proof of concept is there, time to finish it (adding more technical features isn't finishing it)
When there is potential, you only need to finish the last bits to make it awesome.
Happy days!
Just typed a few paragraphs as an answer... But then I realized that this might be misunderstood once more, so I deleted it all. The fewer text and explanations, the fewer misunderstandings I hope! My social/forum fu seems just not that good.
Please keep posting feature requests, or even better use the gitlab tracker so they don't get forgotten completely. Over there people also can vote on issues to indicate demand (A bit delusional when there's 14 possible users atm, I know).
Please keep posting feature requests, or even better use the gitlab tracker so they don't get forgotten completely. Over there people also can vote on issues to indicate demand (A bit delusional when there's 14 possible users atm, I know
).Bart, I see a slight cultural difference. ;-)
Dutch people will not automatically tell another person to change behaviour (I am not offended, BTW), but once we start discussions, we usually don't stop or hold back for reasons outside of the immediate discussion.
I am happy that the nature of "free" development is discussed on diyaudio for a change. I think it is true that many developments stall because no one contributes, but also because many developers are not really after contributions or opinions. It would be good if there was some insight in what the general public of diyaudio can and cannot contribute, and what a developer can and cannot expect. Apparently this is not the thread to continue and of course I will respect that.
I am not worried for, and in fact impressed by Jürgen, he knows what he wants, why he's here and how to filter in the replies.
Dutch people will not automatically tell another person to change behaviour (I am not offended, BTW), but once we start discussions, we usually don't stop or hold back for reasons outside of the immediate discussion.
I am happy that the nature of "free" development is discussed on diyaudio for a change. I think it is true that many developments stall because no one contributes, but also because many developers are not really after contributions or opinions. It would be good if there was some insight in what the general public of diyaudio can and cannot contribute, and what a developer can and cannot expect. Apparently this is not the thread to continue and of course I will respect that.
I am not worried for, and in fact impressed by Jürgen, he knows what he wants, why he's here and how to filter in the replies.
Good day phofman
I suspected that it does see the HDMI device but I was assuming that it's detecting the television (2ch) but not the HDMI audio extractor (8ch).
Here's the output of the pacmd list-cards command
Code:
pi@raspberrypi:~ $ pacmd list-cards
1 card(s) available.
index: 0
name: <alsa_card.platform-soc_audio>
driver: <module-alsa-card.c>
owner module: 6
properties:
alsa.card = "0"
alsa.card_name = "bcm2835 ALSA"
alsa.long_card_name = "bcm2835 ALSA"
alsa.driver_name = "snd_bcm2835"
device.bus_path = "platform-soc:audio"
sysfs.path = "/devices/platform/soc/soc:audio/sound/card0"
device.form_factor = "internal"
device.string = "0"
device.description = "Built-in Audio"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card"
profiles:
output:analog-mono: Analog Mono Output (priority 700, available: unknown)
off: Off (priority 0, available: unknown)
active profile: <output:analog-mono>
sinks:
alsa_output.platform-soc_audio.analog-mono/#0: Built-in Audio Analog Mono
sources:
alsa_output.platform-soc_audio.analog-mono.monitor/#0: Monitor of Built-in Audio Analog Mono
ports:
analog-output: Analog Output (priority 9900, latency offset 0 usec, available: unknown)
properties:Thanks again
OK, but what does the aplay --dump-hw-params report - 2 channels or 8 channels? Please post it here the output for both HDMI devices (hw:0,1 and hw:0,2).
Your PA does not list (i.e. see) the HDMI device at all. The output says that only the mono analog audio was detected by udev. I wonder - do you have your HDMI audio enabled? I do not use RPi, I do not know how to do that, sorry.
Charlie Laub has good knowledge of RPi and HDMI, you can ask him https://www.diyaudio.com/forums/members/charlielaub.html
Humm... "aplay --dump-hw-params" command just hangs until I Ctrl+C out.
I just noticed that my HDMI audio no longer works at all, even when I remove the extractor and connect the television directly. strange, it worked before
No change when I go into Raspi-Config and select Force HDMI Audio. I guess I broke something.
You need to supply the device so that aplay knows what to test... Like this:
Code:
aplay -D hw:0,3 --dump-hw-params /dev/zeroI am assuming that ALSA sees the bcm2835 as card 0, which is what I can tell from your recent post containing the output from pacmd list-cards. From what I recall, usually subdevice for the HDMI output is #3, thus hw:0,3. Try it and post the output.
Last edited:
Hi CharlieLaub,
"aplay -D hw:0,3 --dump-hw-params /dev/zero" results in
aplay: main:828: audio open error: No such file or directory
If you do not specify any input file to read samples from, it reads from standard input which looks like hanging. You have to specify some wav file or simple /dev/zero (infinite source of zeros).
Everything makes sense. If you recall your aplay -l:
Code:
pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
Subdevices: 6/7
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0You have one card ID=0 and devices 0 (analog output - hw:0,0, with 7 subdevices but we do not care about them now), device 1 (HDMI - hw:0,1) and device 2 (HDMI1 - hw:0,2). There is no device 3 for card 0 (hw:0,3) in your system.
Each device is in fact a file in /dev/snd/:
Code:
pavel@precision:~$ ls /dev/snd/pcm*
/dev/snd/pcmC0D0c /dev/snd/pcmC0D1p /dev/snd/pcmC1D3p
/dev/snd/pcmC0D0p /dev/snd/pcmC1D0c /dev/snd/pcmC1D7p
/dev/snd/pcmC0D1c /dev/snd/pcmC1D0p /dev/snd/pcmC1D8pwhere e.g. pcmC0D1c means hw:0,1 capture and pcmC1D8p means hw:1,8 playback. You asked aplay to use hw:0,3 which would be represented by file /dev/snd/pcmC0D3p. Since no such file exists in your system, you received the "no such file" message.
It's actually rather straightforward and logical once you learn the principles.
So what does aplay -v --dump-hw-params -D hw:0,1 /dev/zero say? And the same for the other HDMI device hw:0,2?
Makes sense. Thanks for explaining this.
Here's what I get for aplay -v --dump-hw-params -D hw:0,(1-2)
Code:
pi@raspberrypi:~ $ aplay -v --dump-hw-params -D hw:0,1 1.mp3
Playing raw data '1.mp3' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0,1":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: [32 128]
CHANNELS: [2 8]
RATE: [44100 192000]
PERIOD_TIME: [10000 743039)
PERIOD_SIZE: [441 32768]
PERIOD_BYTES: [1776 524288]
PERIODS: [1 75)
BUFFER_TIME: (2296 743039)
BUFFER_SIZE: [441 32768]
BUFFER_BYTES: [1764 131072]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- S16_LE
pi@raspberrypi:~ $ aplay -v --dump-hw-params -D hw:0,2 1.mp3
Playing raw data '1.mp3' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0,2":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: [32 128]
CHANNELS: [2 8]
RATE: [44100 192000]
PERIOD_TIME: [10000 743039)
PERIOD_SIZE: [441 32768]
PERIOD_BYTES: [1776 524288]
PERIODS: [1 75)
BUFFER_TIME: (2296 743039)
BUFFER_SIZE: [441 32768]
BUFFER_BYTES: [1764 131072]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- S16_LE
pi@raspberrypi:~ $Try to add the option "-f cd" (44.1kHz, 16bit) to your use of "aplay".
I think it's trying to use defaults (8kHz, 8 bit).
Also, "aplay" does not decode mp3 files. You could use /dev/random if you really want to produce white-ish noise Just use /dev/zero (silence) or a *.wav file as input for the diagnostic command suggested.
I think it's trying to use defaults (8kHz, 8 bit).
Also, "aplay" does not decode mp3 files. You could use /dev/random if you really want to produce white-ish noise
Just use /dev/zero (silence) or a *.wav file as input for the diagnostic command suggested.Perfect. Now we know that both HDMI devices offer 2 and 8 channels (maybe some in between but that is not reported by the hw-params dump), and unfortunately just 16bit sample. The 24bit sample is being discussed in other threads, again Charlie knows more.
As next step I would suggest to try playing something through the multichannel HDMI. For testing 16bit samples only you can use speaker-test. For testing 24bit samples a pre-generated 8ch file would be required since speaker-test cannot output 24bit samples yet. However we need 16bit only, speaker-test will do
This command
should output 192k/16b pink noise to all 8 channels sequentially channel by channel. Again please try it for both hw:0,1 and hw:0,2.
Once we know the HDMI device(s) are functional, we can step one layer up to pulseaudio.
As next step I would suggest to try playing something through the multichannel HDMI. For testing 16bit samples only you can use speaker-test. For testing 24bit samples a pre-generated 8ch file would be required since speaker-test cannot output 24bit samples yet. However we need 16bit only, speaker-test will do
This command
Code:
speaker-test -r 192000 -D hw:0,1 -c 8should output 192k/16b pink noise to all 8 channels sequentially channel by channel. Again please try it for both hw:0,1 and hw:0,2.
Once we know the HDMI device(s) are functional, we can step one layer up to pulseaudio.
Last edited:
The speaker test yielded no sound from any of the 8 channels. I've used the HDMI extractor it in the past in JRiver running on TinkerOS so I'm sure it works... I'll try it later this evening on another computer, just in-case it somehow got damaged between then and now.
Thanks for all of your help
Thanks
Building pulseaudio with SOXR support
Just compile a small set of shell scripts to automate building pulseaudio from debian source package with support for the SOXR resampler enabled. This is for those who use a distro like linux mint which still hasn't updated their build environment to include libsoxr-dev
You can check available resampler methods with the command
If you don't see the three lines
in there, you're also missing libsoxr support.
Here are the scripts: Jurgen Herrmann / pulseaudio_with_soxr * GitLab
To use them (more detailed instructions in the README.md):
Please tell me if this is of general interest and should live in it's own thread...
Just compile a small set of shell scripts to automate building pulseaudio from debian source package with support for the SOXR resampler enabled. This is for those who use a distro like linux mint which still hasn't updated their build environment to include libsoxr-dev
You can check available resampler methods with the command
Code:
pulseaudio --dump-resample-methodsIf you don't see the three lines
Code:
soxr-mq
soxr-hq
soxr-vhqHere are the scripts: Jurgen Herrmann / pulseaudio_with_soxr * GitLab
To use them (more detailed instructions in the README.md):
Code:
git clone [url=https://gitlab.com/t-5/pulseaudio_with_soxr.git]Jurgen Herrmann / pulseaudio_with_soxr * GitLab[/url]
cd pulseaudio_with_soxr
./build.sh
./install.sh
./hold.sh
./clean.shPlease tell me if this is of general interest and should live in it's own thread...
I moved the discussion about FIR stuff into a new thread:
Let's build a FIR convolver for Pulseaudio Crossover Rack
Let's build a FIR convolver for Pulseaudio Crossover Rack
While there was no sound, did speaker-test print out the typical Channel Front Right, Channel Front Left, ... or did it spit some error?
Did you try for both hw:0,1 and hw:0,2, with silence?
Digital outputs have usually mute switches in alsa controls. Let's see if perhaps they are not muted. While playing speaker-test to the HDMI (and no sound produced), please take output of
Code:
amixer -c 0 contentsand post it here. It will list all alsa controls defined by your soundcard and their current setting.
Last edited:
Yes, when I run the speakertest I see the following in infinite loop:
Code:
pi@raspberrypi:~ $ speaker-test -r 192000 -D hw:0,1 -c 8
speaker-test 1.1.8
Playback device is hw:0,1
Stream parameters are 192000Hz, S16_LE, 8 channels
Using 16 octaves of pink noise
Rate set to 192000Hz (requested 192000Hz)
Buffer size range from 1920 to 8192
Period size range from 1920 to 8192
Using max buffer size 8192
Periods = 4
was set period_size = 1920
was set buffer_size = 8192
0 - Front Left
4 - Center
1 - Front Right
7 - Side Right
3 - Rear Right
2 - Rear Left
6 - Side Left
5 - LFE
Time per period = 23.977808The same things occurs on hw:0,2
Also, when I run amixer -c 0 contents:
Code:
pi@raspberrypi:~ $ amixer -c 0 contents
numid=3,iface=MIXER,name='PCM Playback Route'
; type=INTEGER,access=rw------,values=1,min=0,max=3,step=0
: values=2
numid=2,iface=MIXER,name='PCM Playback Switch'
; type=BOOLEAN,access=rw------,values=1
: values=on
numid=1,iface=MIXER,name='PCM Playback Volume'
; type=INTEGER,access=rw---R--,values=1,min=-10239,max=400,step=0
: values=400
| dBscale-min=-102.39dB,step=0.01dB,mute=1
numid=5,iface=PCM,name='IEC958 Playback Con Mask'
; type=IEC958,access=r-------,values=1
: values=[AES0=0x02 AES1=0x00 AES2=0x00 AES3=0x00]
numid=4,iface=PCM,name='IEC958 Playback Default'
; type=IEC958,access=rw------,values=1
: values=[AES0=0x00 AES1=0x00 AES2=0x00 AES3=0x00]I'm going to flash a microSD so that I run this same test on the TinkerBoard running Linaro. I'll let you know what happens there. (just to ensure that the HDMI extractor is not faulty).
I'll keep you posted