Wolfson now working with pulseaudio

I find it really strange that you couldn't get pulseaudio to work with wolfson. Here it worked pretty much out of the box once I told it to use it.

On ragnar's image, you can instruct pa to use the wolfson by adding this line to /etc/pulseaudio/default.pa if running per user session, or to /etc/pulseaudio/system.pa if running as system daemon:

set-default-sink 1

Where "1" is the index of the wolfson that you get from

$ pacmd list-cards

or

$ pactl list.

if you are running it as system daemon (pacmd seems to be incapable of finding the running daemon).

I haven't tried the HD files (are they even in ragnar's image? I couldn't find them) and don't have any other lying around, but I've playing around with it playing from different sources, and it works flawlessly.

There are no HD audio files included in my image, since it's just a patched standard Raspbian from the Foundation.

You can find a bunch of HD files here: http://www.2l.no/hires/

--

Ragnar

God, I feel like such an idiot.

Yep, Jose, I did try setting:

set-default-sink 1

in the /etc/pulse/default.pa. It was one of the first things I tried. However, I couldn't hear anything, because I was only playing around with the samples from Wolfson, and they refused to play.

So, I revisited this problem again after imaging Ragnar's version, and this time I had some 16/44.1k files and they played perfectly fine. Turns out, it's pulseaudio's fault for not being able to play 24/96k files, not the provided kernel or the wolfson card.

My logic got screwed up somewhere . Well, at least now I have a shiny kernel that's optimized for music. Thanks.

Oh, I know that stupid feeling when dealing with pulseaudio. It is a wonderful piece of software, but it isn't exactly friendly with non-standard desktop setups, so sorry for the pedantic comment above: you never know what people may or may not have found when dealing with PA.

Totally off-topic, but I can't think of a better place to ask: Has anybody gotten pacmd to work with the system daemon? I get "No pulseaudio daemon" every time I try to use it. pactl works, though.

Also off topic: any experience getting RTP to work? I spent all of yesterday trying to get it to work; I had a linux machine broadcasting RTP to the LAN, with the pi connected through ethernet and wifi, and no sound, no matter how I tweaked PA's settings and modules. Then, after a couple of hours after giving up on it, I unplugged the ethernet cable on the Pi, and ANOTHER machine that I had forgotten was configured to receive RTP audio started blasting the linux machine's stream. Any pointers on where to start trying to figure out what is going on with RTP in the LAN?

I'll try the HD files linked by ragnar when I get home, just to make sure the audio stack part works.

Jose,

I did get it to work one time in system mode. I'll try to see if I could recreate it. I remember I had to enable a few X11 stuff, export a couple ENV vars, and execute pacmd as the 'pulse' user. Yes, it was ugly, but that seemed to be the only way to get to execute and overcome the so-called security measures built into PA.

I'm curious, though, is there a specific reason why you need to run it in system mode? I personally like funneling everything to PA using 'per-user' mode, as it simplifies configuring, testing, and ultimately using all over the home. You probably know, but both pactl and pacmd works in per-user mode.

The link Ragnar posted points to a different place than where I got my sample files. I got mine off this very site, on the main Wolfson Audio card product page. On the rightmost tab there's a link to download the whole sampler set. Ragnar's link has samples of DSD files (which, sad to say, the wolfson card can't play), as well as some 24/192k files.

I downloaded some of these to test, and found yet another problem with pulseaudio. My PA config thus far played both 16/44.1 and 24/96k files fine, but wouldn't play the 24/192k files. Fine, I thought. I just upped the alternate-sample-rate to 192000 in /etc/pulse/daemon.conf, which then played these files fine, but would choke on the lesser files. Reverting back to alternate-sample-rate = 96000 would play the lesser files fine, but would choke on the 192k. Each time, I see in the logs (produced by pulseaudio -vvvvv), messages of rewinding over and over again, AND complaints about wolfson's arizona(?) something or rather before segfaulting.

Needless to say, you seem way ahead of me in having figured out the card with PA, since I'm still tinkering with bitrates while you're already testing out RTP over the network (I hope to get there soon), but have you been able to play 44.1k, 96k, AND 192k with the same PA config?

Also, if I may ask: what version of PA are you using? The stock 2.0 version from the official repo, or later version from the PA site? I may try compiling one of the newer version and see how that works before I drop it. Yes, it's very nice piece of software, but very confusing and unwieldy. I'm wondering if something like jack can be a replacement...

Well, maybe I'm too old fashioned, but I am very attached to the idea that a hardware management service like audio should not be user confined... Specially in a headless machine, where there are no real "users". I guess it makes no sense fighting with PA on this... I was just trying to replicate the setup I had in my old x86 music server (which is what I am trying to replace with the pi as music player), but that was a less ambitious setup.

If I were to run PA as per-user sessions, would I be able to grant access to the daemons that require audio, or would they have to run as the "pi" user?

Everything related to PA is with official binaries from debian repos. I have only compiled some client apps locally (ie, an mpd fork, gmedia-renderer, that kind of stuff).

If I'm ahead of you, it is only because I have not tried to do any fancy stuff, just getting the advertised PA features to work. HD files do play fine if you specify the proper alternate-sampling-rate, but having it hardcoded in the conf file is clearly unacceptable. I guess PA is just not designed for this kind of stuff. For the record: the RTP issues I'm having seem to be outside PA, because tcpdump does not show any RTP traffic at all on the Pi... I blame the wifi dongle I had attached, but I have not tested extensively.

Bottomline: I have actually thought a lot about not using PA at all. It seems to be too much "consuemr-oriented" for any non-standard (ie, headless, X-less) setup. The obvios alternative would be JACK, but the last time I tried it, I was completely incapable of getting it to do anything, but that was years ago and I didn't try that hard. Do you have any experience with JACK?

I make every audio request run as the 'pi' user. Although I guess you can fudge it to allow access via group that pi belongs in. Or in an entirely different group like 'pa-audio' or something and put 'pi' in there along with other users.

PA is a PITA, in that it always tries to resample and the parameters are hardcoded. But it's gotten better, as previous versions was only limited to 44.1k. At least now it allows for a couple of different rates. I also see how it has to resample things, since one of its core features is to distribute the music to other devices that probably require it.

I don't have any experience with Jack. From what I can tell, it doesn't have as many features as PA and seems geared more toward music creation rather than consumption. I'm going to try hand compiling a more updated version of PA before I start on Jack, though.