INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Linux => Topic started by: stevemac on May 11, 2015, 01:28:55 am
-
Hi,
Raspberry PI 2 Model B
NOOBS installation (Raspbian)
Level of expertise: Low
I have a PI successfully running JRiver, but am having some problems trying to get 5.1 FLAC files playing correctly. They come out as stereo
The PI is connected via HDMI to a Pioneer receiver which is capable of 7.1
The same FLAC file plays correctly from an Intel NUC with Win 8.1 & JRiver to the same receiver. This leads me to believe I've a problem with the PI setup or the JRiver setup on the PI
the audio path in JRiver shows
- Input: 96kHz 24bit 6ch from source format FLAC
- Output: 48kHz 32bit 6ch using ALSA (direct connection)
I've spend a fair amount of time googling ALSA & config settings but haven't solved the issue. Being inexperienced in UNIX / LINUX isn't helping :)
Any thoughts on some basic checks I can perform?
From config.text
pi@SteveMacPi1 ~ $ cat /boot/config.txt
# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# NOOBS Auto-generated Settings:
hdmi_force_hotplug=1
config_hdmi_boost=4
overscan_left=24
overscan_right=24
overscan_top=16
overscan_bottom=16
disable_overscan=0
start_x=1
gpu_mem=128
# JRiver Settings
framebuffer_depth=32
framebuffer_ignore_alpha=1
framebuffer_width=1920
framebuffer_height=1080
# Original Setting
#hdmi_group=2
#hdmi_mode=82
#hdmi_drive=2
#updated Settings
hdmi_group=1
hdmi_mode=31
hdmi_drive=2
hdmi_force_edid_audio=1
from /etc/asound.conf (which I created in hope...)
pi@SteveMacPi1 /etc $ cat asound.conf
pcm.!default {
type hw
card 0
}
ctl.!default {
type hw
card 0
}
pi@SteveMacPi1 /etc $
Media Info on one of the tracks I tested
Complete name : X:\Music\FLAC\Fleetwood Mac\Rumours (6ch 24bit 96kHz)\The Chain.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 232 MiB
Duration : 4mn 25s
Overall bit rate mode : Variable
Overall bit rate : 7 336 Kbps
Album : Rumours (6ch 24bit 96kHz)
Track name : The Chain
Track name/Position : 7
Performer : Fleetwood Mac
Composer : Lindsey Buckingham
Genre : Rock
Recorded date : 1977
BPM : 75
Cover : Yes
Cover type : Cover (front)
Cover MIME : image/jpeg
Rating : 5
INTENSITY : 2
TOOL NAME : Media Center
TOOL VERSION : 20.0.99
VOLUME LEVEL (R128) : -9.6837902069091797
PEAK LEVEL (R128) : +0.2 dBTP; +0.2 Left; +0.2 Right; -6.0 Center; -9.3 Sub; -4.0 SL; -3.3 SR
JR_DATE : 28162
DYNAMIC RANGE (R128) : 12.286250114440918
PEAK LEVEL (SAMPLE) : +0.0 dB; +0.0 Left; +0.0 Right; -6.0 Center; -9.3 Sub; -4.0 SL; -3.3 SR
DYNAMIC RANGE (DR) : 13
VOLUME LEVEL (REPLAYGAIN) : -4.6837902069091797
thanks,
Steve
-
It seems like you are doing everything correct.
Perhaps the pi can't do 6 channel over HDMI?
-
Thanks Bob - appreciate your review
Hopefully someone else using the PI can let me know if they have had any success with 5.1 FLAC over HDMI
cheers,
Steve
-
I'll have a look for you tonight.
-
thanks Hilton - no urgency at this end. The more I tinker - the more I should learn
cheers,
Steve
-
I compiled and installed alsacap to have a look and it appears by default that HDMI is configured only for 2 channel.
Here's the output from alsacap. (scans the audio devices in the system)
pi@raspberrypi ~/Downloads/alsacap $ ./alsacap
*** Scanning for playback devices ***
Card 0, ID `ALSA', name `bcm2835 ALSA'
Device 0, ID `bcm2835 ALSA', name `bcm2835 ALSA', 8 subdevices (8 available)
1..2 channels, sampling rate 8000..48000 Hz
Sample formats: U8, S16_LE
Subdevice 0, name `subdevice #0'
Subdevice 1, name `subdevice #1'
Subdevice 2, name `subdevice #2'
Subdevice 3, name `subdevice #3'
Subdevice 4, name `subdevice #4'
Subdevice 5, name `subdevice #5'
Subdevice 6, name `subdevice #6'
Subdevice 7, name `subdevice #7'
Device 1, ID `bcm2835 ALSA', name `bcm2835 IEC958/HDMI', 1 subdevices (1 available)
2 channels, sampling rate 44100..48000 Hz
Sample formats: S16_LE
Subdevice 0, name `subdevice #0'
-
I just checked and the Pi can do 8ch PCM over HDMI or bitstreaming.
-
Folks over on the raspberry Pi forums are talking about getting multi-channel output from the Pi's HDMI output with XBMC and other software players, so it's possible from a hardware perspective.
However, the forum posts suggest that those players had to write their own interface or modify the ALSA drivers to do it, the stock ALSA drivers seem to only support 2 channel (as suggested by Hilton's ALSACAP output).
I just checked and the Pi can do 8ch PCM over HDMI or bitstreaming.
With ALSA? Or some other way? Did you have to do any special configuration?
-
I believe the HDMI EDID is only read during boot on the Pi. You have to have your receiver turned on before you boot the Pi.
-
OK I did some actual testing and I can't get more than 2ch over HDMI either.
I get the same results as Steve.
There must be a way as other media players are getting this on HDMI:
PCM supported: Max channels: 8, Max samplerate: 192kHz, Max samplesize 24 bits.
AC3 supported: Max channels: 6, Max samplerate: 48kHz, Max rate 640 kb/s.
DTS supported: Max channels: 7, Max samplerate: 96kHz, Max rate 1536 kb/s.
DTS_HD supported: Max channels: 8, Max samplerate: 192kHz, Max rate 8 kb/s.
-
My research suggests that they essentially wrote their own interfaces for it or modified and recompiled the ALSA drivers (which currently have a hard 2-channel limit baked in). I haven't gotten down in the weeds on this, but it might be possible to just gently tweak the ALSA driver and get it working.
-
Hilton & mwilliams - thanks for taking the time to look into this
From a processing perspective I think the PI is borderline capable of handling the multi-channel FLAC files. In my case the tracks are getting resampled from 96kHz to 48kHz on the PI. I'm getting semi-regular drop-outs (perhaps 1 sec every 2nd track).
I don't have a lot of these files. Might try converting to another format & see how that works
cheers,
Steve
-
Hilton & mwilliams - thanks for taking the time to look into this
From a processing perspective I think the PI is borderline capable of handling the multi-channel FLAC files. In my case the tracks are getting resampled from 96kHz to 48kHz on the PI. I'm getting semi-regular drop-outs (perhaps 1 sec every 2nd track).
I don't have a lot of these files. Might try converting to another format & see how that works
cheers,
Steve
Yes your right about on the limit for resampling, however if we can get it to output native 96k/24bit/6ch or 8ch PCM which most AVR's will accept, then there's no resampling going on the Pi will handle it fine.
The problem your seeing is the resampling from 96k to 48k which the Pi cant do with 6ch.
-
I compiled and installed alsacap to have a look and it appears by default that HDMI is configured only for 2 channel.
Here's the output from alsacap. (scans the audio devices in the system)
pi@raspberrypi ~/Downloads/alsacap $ ./alsacap
*** Scanning for playback devices ***
Card 0, ID `ALSA', name `bcm2835 ALSA'
Device 0, ID `bcm2835 ALSA', name `bcm2835 ALSA', 8 subdevices (8 available)
1..2 channels, sampling rate 8000..48000 Hz
Sample formats: U8, S16_LE
Subdevice 0, name `subdevice #0'
Subdevice 1, name `subdevice #1'
Subdevice 2, name `subdevice #2'
Subdevice 3, name `subdevice #3'
Subdevice 4, name `subdevice #4'
Subdevice 5, name `subdevice #5'
Subdevice 6, name `subdevice #6'
Subdevice 7, name `subdevice #7'
Device 1, ID `bcm2835 ALSA', name `bcm2835 IEC958/HDMI', 1 subdevices (1 available)
2 channels, sampling rate 44100..48000 Hz
Sample formats: S16_LE
Subdevice 0, name `subdevice #0'
There is a modified version of alsacap in the MC arm builds (I changed it to list discreet sample rates instead of a range).
It's
/usr/lib/jriver/Media\ Center\ 20/alsacap
-
I stumbled across some info about HDMI channel mapping today which kind of explains the problem.
The Pi used to read EDID info and set the proper HDMI mapping. Because so many EDID's were incorrect they then changed it so it's user configurable.
The default map is for 2 channel only.
Running this command sets it to 7.1 which I can confirm works at a hardware level, as my amp lights up with 7.1 pcm 48khz.
Without the command I only get 2ch 48k.
$ vcgencmd hdmi_channel_map 0x13fac688
to which it replies> hdmi_channel_map=0x13fac688
There are some commands that you can put in your config.txt to set this at boot as it doesn't survive a reboot.
So this is the first step in getting it to work.
The MC20 and alsa or pulse though will still only output 2ch even if set to multichannel in MC20.
I did some checks with the room correction and putting speakers in solo mode and each channel is being decoded and output through in stereo. So it's being downmixed, probably by alsa.
So it is indeed possible however I believe Bob and the team will need to work on channel mapping and probably some other bits specific to the Pi. (this is different between Pi and Pi2 BTW from what I understand)
Here's the thread that pointed me at HDMI channel mapping.
https://github.com/raspberrypi/linux/issues/450
How the OMXplayer does HDMI channel mapping
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/omxplayer/OMXAudio.cpp#L442
Further info
hdmi_channel_map takes a 24-bit number as a parameter that consists of 8 3-bit fields describing the mapping of input channel to output channel.
The top 8 bits describe the speaker mapping from Table 28 (Audio InfoFrame Data byte 4) of CEA 861 spec.
I am also running in hdmi_drive=2 HDMI mode, and with hdmi_group=2 hdmi_mode=82 so I can force a resolution without a monitor connected so when I RDP I have 1920x1080 resolution. Don't know if that makes any difference, but I suspect it does.
I'll do some more testing with the above hdmi modes at defaults.
-
They are also working on making Analogue and HDMI separately addressable which will improve the situation.
https://github.com/raspberrypi/linux/issues/847
-
Thanks Hilton
I'd tried vcgencmd hdmi_channel_map 0x13fac688 & got the reply, but as you've pointed out it doesn't fix the entire issue.
FYI - my settings for HDMI are hdmi_group=1, hdmi_mode=31, hdmi_drive=2, hdmi_force_edid_audio=1
cheers,
Steve
-
Here's an interesting command hidden away. Didn't fix anything, but it confirms my AMP is being detected as able to decode multichannel.
pi@raspberrypi ~ $ tvservice
Usage: tvservice [OPTION]...
-p, --preferred Power on HDMI with preferred settings
-e, --explicit="GROUP MODE DRIVE" Power on HDMI with explicit GROUP (CEA, DMT, CEA_3D_SBS, CEA_3D_TB, CEA_3D_FP)
MODE (see --modes) and DRIVE (HDMI, DVI)
-t, --ntsc Use NTSC frequency for HDMI mode (e.g. 59.94Hz rather than 60Hz)
-c, --sdtvon="MODE ASPECT" Power on SDTV with MODE (PAL or NTSC) and ASPECT (4:3 14:9 or 16:9)
-o, --off Power off the display
-m, --modes=GROUP Get supported modes for GROUP (CEA, DMT)
-M, --monitor Monitor HDMI events
-s, --status Get HDMI status
-a, --audio Get supported audio information
-d, --dumpedid <filename> Dump EDID information to file
-j, --json Use JSON format for --modes output
-n, --name Print the device ID from EDID
-h, --help Print this information
pi@raspberrypi ~ $ tvservice -s
state 0x12001a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
pi@raspberrypi ~ $ tvservice -a
PCM supported: Max channels: 8, Max samplerate: 192kHz, Max samplesize 24 bits.
AC3 supported: Max channels: 6, Max samplerate: 48kHz, Max rate 680 kb/s.
DTS supported: Max channels: 6, Max samplerate: 96kHz, Max rate 1536 kb/s.
-
Since MC does multichannel just fine in non-pi linux I think we have an issue with how the pi is presenting ALSA devices.
On a desktop linux platform we see hardware devices (like front: and hdmi:) AND non-hardware devices (like default: and sysdefault:). On the pi we see only the non-hardware devices. I think this means the mixer is preventing the hardware devices from being shown or there simply is no public hardware interface to those devices. I'm not sure how to get around this.
-
Since MC does multichannel just fine in non-pi linux I think we have an issue with how the pi is presenting ALSA devices.
On a desktop linux platform we see hardware devices (like front: and hdmi:) AND non-hardware devices (like default: and sysdefault:). On the pi we see only the non-hardware devices. I think this means the mixer is preventing the hardware devices from being shown or there simply is no public hardware interface to those devices. I'm not sure how to get around this.
There are some settings in the alsa.conf that may get this going.
I changed a couple things and got a few more default devices showing up internally. I'll keep playing. :)
Anyone else out there don't muck around with this until we've got it working as you could completely mess up alsa.
If you cant resist the urge to tinker do the following first to make a backup.
sudo cp /usr/share/alsa/alsa.conf /usr/share/alsa/alsa.conf.bak
#these are unproven to fix anything, it's just for experimentation at this stage.
Changes I made in /usr/share/alsa/alsa.conf
# show all name hints also for definitions without hint {} section
defaults.namehint.showall on #default off - I changed to on
# show just basic name hints
defaults.namehint.basic on
# show extended name hints
defaults.namehint.extended on #default off - I changed to on
When I now run aplay-L I get a whole bunch of new devices showing up. MC20 can also see these devices.
pi@raspberrypi ~ $ aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
pulse
Playback/recording through the PulseAudio sound server
mmap0
default
sysdefault:CARD=ALSA
bcm2835 ALSA, bcm2835 ALSA
Default Audio Device
dmix:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample mixing device
dmix:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample mixing device
dsnoop:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample snooping device
dsnoop:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample snooping device
hw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct hardware device without any conversions
hw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct hardware device without any conversions
plughw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Hardware device with all software conversions
plughw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Hardware device with all software conversions
I'll go try HW device 1 and see what I get.
-
No change but I worked out why. The kernel isn't compiled to support it.
Here's the settings from the sound/arm/bcm2835-pcm.c in the kernel source.
.formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000,
.rate_min = 8000,
.rate_max = 48000,
.channels_min = 1,
.channels_max = 2,
Changing this to 192 and 8 channel and recompiling the kernel as per below should fix it. Im going to attempt this now. I haven't recompiled too many kernels though!
.formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_192000,
.rate_min = 8000,
.rate_max = 192000,
.channels_min = 1,
.channels_max = 8,
-
This is very cool. I'm following it closely!
-
I'm also following this issue with interest ;D
-
& that makes three of us. I have skimmed so many sites & posts about ALSA, its settings and sound issues for the PI without success. Appreciate the effort & impressed with the skills.
cheers,
Steve
-
Well I finally cross compiled the kernel on Ubuntu 14.04 64bit after a lot of stuffing around.
The documentation out there is incomplete and out of date which made if very difficult, but I got there in the end.
The kernel cross compiled in about 4mins running in an Ubuntu VM on Virtualbox on my windows 8.1 machine with a X4960 @ 4.7Ghz. (with 12 cores setup for the VM it used 100% CPU)
The changed settings in the kernel didn't work though. I just get whitenoise at high bitrates.
Now I've got the workflow and compiling sorted I'll play around with some more sound driver changes over the next week.
-
I've made some progress.
I can play 24bit 192k downsampled to 16bit 192k.
It would seem it's the 24LE and 32LE formats that aren't decoding properly.
-
Impressive & well done. How many channels are you able to send over HDMI?
-
I think they have some similar problems at volumio. I've posted a link below to thread which discusses a possible fix.
https://volumio.org/forum/raspberry-and-hdmi-sample-rates-t2643.html
Sorry if this upsets anyone...talking about a competitor on this forum. I own a license of JRiver and will definitely go for a site license if JRiver for pi becomes a real deal FWIW.
-
I think they have some similar problems at volumio. I've posted a link below to thread which discusses a possible fix.
https://volumio.org/forum/raspberry-and-hdmi-sample-rates-t2643.html
Sorry if this upsets anyone...talking about a competitor on this forum. I own a license of JRiver and will defiantly go site license if JRiver for pi becomes a real deal FWIW
JRiver for pi is official, you just need a linux license or a master license: http://yabb.jriver.com/interact/index.php?topic=97630.0
-
I think they have some similar problems at volumio. I've posted a link below to thread which discusses a possible fix.
https://volumio.org/forum/raspberry-and-hdmi-sample-rates-t2643.html
Sorry if this upsets anyone...talking about a competitor on this forum. I own a license of JRiver and will definitely go for a site license if JRiver for pi becomes a real deal FWIW.
Thanks I'd seen that one in my research. It's on my list of things to try out their kernel image. I'll also contact Stephane the author of those kernel changes which are very similar to what I've been doing.
He went through the same steps as me and had it working @16bit 192k before he got it working at 24bit. So I'm not far off.
I've discovered most of the other media players are bypassing ALSA and using the Broadcom Openmax API instead which communicates directly with the videocore engine.
I don't think that's an option for the MC development team as its a very specific and niche API that wouldn't be usable anywhere else.
My understanding is the analogue output has at best 14bit output using PWM to resample for ALSA where as the HDMI output uses the videocore engine to resample, which is what makes it more complicated.
This is why the hardware devices are completely abstracted from ALSA and why they don't appear like other sound card devices in ALSA.
To answer the other question about number of HDMI channels working, I'll have to do some more testing as I've been testing connected to one of my HDMI monitors on my main workstation which is only 2ch.
-
ALSA is detecting streams properly but the streams aren't being decoded above 16bit depth.
All sample rates play from 8k to 192k @ 16bit.
Time to dig in the kernel some more...
16bit 192K plays ok (S16_LE)
pi@raspberrypi ~ $ cat /proc/asound/card0/pcm1p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 16384
buffer_size: 16384
S24LE plays white noise
pi@raspberrypi ~ $ cat /proc/asound/card0/pcm1p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 8192
S24_3LE plays white noise
pi@raspberrypi ~ $ cat /proc/asound/card0/pcm1p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 8192
S32_LE plays white noise
pi@raspberrypi ~ $ cat /proc/asound/card0/pcm1p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 8192
-
I've done what I can with this and there is some more work needed in the core ALSA drivers for HDMI that is beyond my capabilities.
I looked at lots of ALSA driver source code to work out if there was anything missing and tried using some driver settings from other devices without luck.
The changes didn't break anything but they didn't make it work either.
Still limited to 16bit audio but at least it'll decode upto 192k now.
I'll check how many channels are working tonight but I suspect it will only work for 2 channels.
I'll also try another kernel image from another distro and see if it works. After that it's upto to someone else with more low-level ALSA driver and core audio skills.
-
Thanks for working on this. Appreciate the effort & time invested
cheers,
Steve
-
I finally decided to give JRiver ARM a try on my pi.
Initially I was not able to play anything above 48k in 2 channel without being downsampled.
I was feeling frisky so I went ahead and updated the kernel per the instructions on the Volumio forum I linked to earlier. With the changes applied I am able to send all of the sample rates my receiver supports with confirmation on the receiver display.
My receiver does not indicate bitdepth so I do not know if it is receiving 16bit or 24bit audio.
Initially, the receiver only indicated two channel audio when playing a high resolution multi-channel FLAC file though the Audio Path button indicates 6 channel 96K is flowing in and out of JRiver with no changes.
I executed the command line "vcgencmd hdmi_channel_map 0x13fac688". At that point my receiver indicated that it was a receiving multi-channel input. However there was no sound from the center or surround speakers. I then played a two channel file and the receiver again reported receiving a multi-channel input though sound only came from the left and right speakers.
After my changes, alsacap indicates the additional sample rates but does not indicate additional channels.
It's worth pointing out that over at volumio, it's not clear if they got multi-channel working (I don't think they did). They got the high sampling rates working and there is no mention higher bit depths working.
I don't think I have advanced the cause but I thought that I would report my efforts to see if they might spark some new ideas.
Matt
-
Today I went in and changed the output format under device settings in JRiver options - audio. The default setting is auto which played fine. I then tried s16_LE, s 24_LE, s24_3LE & s32_LE. All played just fine. I was playing a 24bit file and I stopped it in between every change. Again, my receiver provides no indication regarding bit depth so I can't be completely certain the pi passed on the bit depth but it's promising.
I read this article http://www.volkerschatz.com/noise/alsa.html which kind of leads me to believe it might be possible to configure the .asoundrc to force multi-channel but that might make all audio present itself as multi-channel. Dunno. The article was written by the same person who created ALSACAP.
I am also thinking that I will look in to posting at the pi foundation to see if I can get any answers. I've read some threads which clearly indicate multi-channel PCM has worked on the pi.
None of this is a deal breaker for me. I switched from Volumio to JRiver running on Raspbian and I prefer the latter.
-
So I posted on the Raspberry Pi Foundation forum.
https://www.raspberrypi.org/forums/viewtopic.php?f=35&t=116953&p=796689#p796689
The response I got was to use openMax to bypass ALSA. I think this is done (somehow) through the hello_audio demo app which uses openMax.
If I go to /opt/vc/src/hello_pi/hello_audio and I run ./hello_audio.bin 1 8 the sine wave plays through all of my speakers. FYI: you have to compile all of the demo apps first. https://www.raspberrypi.org/documentation/usage/demos/
I really have no idea how to loop audio through hello_audio though. I see that users of VLC player do it. I'll try and look into that further.
I'm pretty wet behind the ears when it comes to Linux so if there are any advanced users still keeping an eye on this thread I would love some help.
Matt
-
I had a look at the demo, but unfortunately I'm not sure that Linux knowledge alone will help you here: that demo program is about 700 lines of C (counting the headers) just to play a sine wave. Someone with a fairly good knowledge of C and how Linux audio drivers work would need to rework that code and then wrap it in an ALSA plugin/driver to get you something that would work with an arbitrary input.
If anyone reading is proficient in C and has the time or interest to work on this, the following page (together with the demo referenced above) appears to include a significant portion of the info you'd need:
http://jan.newmarch.name/RPi/OpenMAX/Audio/
-
Thanks for taking a look. I'll keep messing about to see if I can figure anything out.
-
There's a pull request in the Raspian GitHub to add multichannel PCM output (192k/24bit/8ch) to the ALSA driver in the Linux kernel:
https://github.com/raspberrypi/linux/pull/1166
More discussion on the topic about the HW capabilities and different implementation approaches here: https://github.com/raspberrypi/linux/issues/1000