I am using this with a Pi Zero (I bought the wireless + DAC + Zero kit).
If I run speaker-test -c2 -t wav I hear what I expect.
However, I have a couple of queries.
I have a WAV file generated by espeak which is mono, not stereo.
When I use aplay to play it back, I get
aplay: set_params:1239: Channels count non available
Also, alsamixer reports:
“This sound device does not have any controls”
Is this expected behaviour?
/Steve
Not sure about the mono WAV file but the alsamixer report sounds right!
Want to send us the WAV file to try here?
Was this ever resolved? I have exactly the same problem.
speaker-test -l5 -c2 -t wav
works, says “front left” 5 times.
aplay -c2 /usr/share/sounds/alsa//Front_Left.wav
Channels count non available
I’m using Wheezy rather than Jessie on a Pi Zero, with the aim of getting the Pi Zero to be a bluetooth speaker for my phone (to my amplifier).
are you sure you are using Wheezy, AFAIK there never was any support for the zero?
anyhow, why are you trying to play a mono file through the pHAT DAC? this is achievable but I believe you’d have to downmix it via an ad hoc asound.conf
on a sidenote, if I understand right you are trying to create an airplay speaker? we have a script specifically for that, but it is solely tested in Raspbian jessie currently.
… which brings me back to your claim you are running Wheezy, are you 100% sure about that? what does cat /etc/os-release has to say about that? what about kernel, which are you running? run uname -a for more information.
or for a more expeditive way to gather info that may help us help you:
curl https://get.pimoroni.com/diagnostic | bashYes, I’m sure I’m running Wheezy - this is a desperate attempt to get the old http://www.instructables.com/id/Turn-your-Raspberry-Pi-into-a-Portable-Bluetooth-A/?ALLSTEPS instructions working.
I managed to make progress by ignoring aplay entirely and just using paplay instead: that didn’t need any further configuration.
My objective is to run the headless Pi Zero as a Bluetooth speaker, preferrably allowing any Bluetooth device to play music through it.
well… sure I guess that with the right kernel a zero can work with wheezy, can’t see why not.
Still, while you may have other reasons to want to persevere with older versions of the bluez stack, the following project is mentioned in the instructable you linked herein:
I had a brief look and it seems very much active at this stage, works in Jessie (at least that is the claim), and has been tested on a zero.
… just in case you missed it anyhow, nothing wrong with your approach but since you used the word ‘desperate’ I thought I’d post a source that may be useful to you :)
It is active and working, as far as I know. I haven’t actually tested the install with a pi zero but I have had it working previously. I’m willing to get it supported if it’s not already. As far as espeak, I haven’t spent much time attending to it, it may come about sometime but I can’t say for sure when I’ll be motivated to get it working. As for now I’ve simply added kodi for use as a GUI. I’m also in the middle of configuring the install to also install lirc so that you can easily use a remote to control it instead of a keyboard.
Hi - I’ve tried the Raspberry-Pi-Audio-Receiver-Install, but with very mixed success.
I started with Jessie-Lite from Jan 2017, because I’m intending this to be a headless Pi Zero installation - it’s supposed to be inside the speaker box for my son’s school project.
The runall.sh went through OK and booted up to the Kodi UI, after pulling in a lot of X11 stuff I’d rather not have.
We did manage to connect to the Pi and play Spotify and Youtube audio through the Pi HDMI output (I think), but only after exiting from the Kodi UI.
I tried again from scratch, leaving out the AirPlay and Kodi sections of runall.sh, and then ran the Pimoroni PHatDac installation script to switch the audio.
Bluetooth will pair, but won’t connect.
With the default class=0x200414 I was seeing syslog messages
bluetoothd[425]: GAP and GATT are mandatory
bluetoothd[425]: gap-gatt-profile profile probe failed for xx:xx:xx:xx:xx:xx
where the MAC address seems to be associated with my Android phone. I’ve switched to class=0x20041c and I don’t even see those any more.
I can’t debug the sound system either. The speaker-test works (but only says Front_Left, never Front_Right, so perhaps there’s a soldering problem somewhere) but neither aplay nor paplay will make any sound. pactl subscribe shows them doing apparently the same things, but no sound comes out.
Help!
yes, it sounds like there is an issue with your pHAT DAC. Did you have it working originally? maybe try to reflow the headphone jack anchors onto the pcb in case there is a bad contact there.
… bluetooth, I’m not sure - what bt adapter are you using and were you able to get it to work in another context?
I don’t know what the install process is for phat DAC, if you want audio from the HDMI you will need to set it up. The /etc/asound.conf is set for card 1, and bcm is on card 0.
I’m using the Cambridge Silicon Radio USB Bluetooth dongle, and I have had all of the moving parts working at least once.
It really seems as though there is some state being kept between sessions by the Bluez code - I’ve just used bluetoothctl to “remove” my device, and now I’ve got the gap-gatt-profile failure again.
can’t say I have found toying with bluetooth on the Pi particularly frustration-free, to be completely honest with you.
I think the version of bluez included in both jessie and wheezy, in my experience, are basically broken, and I have only been able to get some results using upstream debian packages.
That won’t work on a zero though, since they are compiled for armv7, but perhaps compiling from source a more recent version might be an option consodering. Or not.
[quote=“BaReinhard, post:10, topic:1980, full:true”]
I don’t know what the install process is for phat DAC, if you want audio from the HDMI you will need to set it up. The /etc/asound.conf is set for card 1, and bcm is on card 0.[/quote]
good point… the phat DAC script disables the on-board, so there is no card 1. It does also overwrite /etc/asound.conf so that’s likely to cause trouble too**.
** I have a revised script to avoid the later as in truth that is unnecessary in jessie, but it hasn’t been deplyed yet,
Well, that clarifies things a bit.
The choices appear to be a) give up now, b) switch to the Pi3 and forget about pretend it’s really viable, or c) try compiling a newer bluez.
That first one looks extremely tempting…
I had a look and there are some packages available for raspbian testing that provide a less antique version of bluez… might be worth giving them a go:
http://mirrordirector.raspbian.org/raspbian/pool/main/b/bluez/
… I’d presume they are armv6. I’ll give them a quick spin tomorrow.
I believe I have added support for the phat DAC, since it still uses the hifiberry-dac dtoverlay, you will only simply have to remove the octothorpe(#) before
dtoverlay=hifiberry-dac in the /boot/config.txt.
I wish I had one to test with but I am only limited to a hifiberry amp+, which works with the same change except using the dtoverlay of
dtoverlay=hifiberry-amp
I have since updated the project with several new features, all of which I have tested manually, I am in the middle of testing with the full install.
A major change that allowed for kodi to use sound cards was adding kodi to the proper groups, I also added root to a couple of groups just in case, but if you don’t want to do a full install just run the following commands:
sudo usermod -a -G lp kodi
sudo usermod -a -G pulse-access,audio root
sudo adduser kodi pulse-access
if your sound card is listed as a different card than card 1, you will also need to change the /etc/asound.conf file to use the proper card number, in place of card 1.
I hope this helps. If it does not please feel free to open an issue on the github page and I will gladly start diagnosing the problem and look for a fix.
EDIT: upon further inspection it is likely kodi doesn’t need the lp groupd, but rather just pulse-access. For the time being I will leave it as I don’t know for certain whether or not it will break anything until I get some further testing done.
It might be my Android phone. I have tried adding the --experimental flag to the bluetoothd, which makes it work for my phone but it refuses to connect to an iPhone 5s.
If that’s the case it should be easy to change, you’ll need to change the /etc/shairport-sync.conf file to the proper card and add a pulse card to the asound.conf
pcm.pulse {
type pulse
card (number)
}
ctl.pulse {
type pulse
card (number)
}
Thanks for your help. I don’t know exactly what made it work, but I do now have a working Pi Zero running Raspbian Jessie Lite successfully accepting Bluetooth connections and routing the audio to the PHAT DAC.
I want to update this thread because likely anyone who has used past installs of the ssrpari may have ran into the problem. There seemed to be a reoccurring issue with sbc errors during Bluetooth playback which was eventually linked to an issue with pulseaudio5, we have since corrected the issue by compiling pulseaudio6 and changing the daemon configuration. You can follow the new script for bt_pa_config.sh lone by line to correct the issue or simply start fresh with the latest raspbian, it for sure works with lite and I found Bluetooth and airplay to work fine on desktop as well but that was with a custom install.