Pulseaudio...

[CPUnltd]

after all my attempts to get a working ALSA bluetooth connection, I'm opting to figure out how to get pulseaudio running... will list all the packages I've grabbed from angstrom's repos in a post or two... most obvious are pulseaudio, paprefs and pavucontrol. I grabbed a few ALSA wrappers too, forget which offhand. May start this again from scratch so I can keep better track of what I'm doing.

In any event. I seem to have it "running" but have no access to the volume control... I'm posting the few .asoundrc configs I've tried, hoping they will give me acces to the volume conrol, but not sure if they even matter... ALL work is being done on an SD install, so I have NO worries of killing my NAND anytime soon. Also pretty sure I can simply re-enable standard ALSA by unchecking pulse in autostart and replacing .asoundrc with a default and finishing up with a reboot.... haven't tested just yet though, so we shall see. In any event, I've finally decided to share what I have so far with everybody to see if more eyes would be a good thing in this venture.

Yell at me all you want (for those who feel like it) I'm under the impression that getting pulseaudio to work (With support for bluetooth) will happen before getting a consistant "fix" for bluetooth in ALSA... I concluded the same on my desktop AND laptop and have been happier ever since... so help if you'd like, but save the drama for your personal blogs. Thank you...

 

[CPUnltd]

pcm.ossmix { 
    type dmix 
    ipc_key 1234 # must be unique! 
    ipc_key_add_uid false   # let multiple users share 
    ipc_perm 0666           # IPC permissions for multi-user sharing 
(octal, default 0600) 
    slave { 
        pcm "hw:0,0"      # you cannot use a "plug" device here, darn. 
        period_time 0 
        period_size 1024 # must be power of 2 
        buffer_size 8192  # dito. It 
       #format "S32_LE" 
       #periods 128 # dito. 
       #rate 8000 # with rate 8000 you *will* hear, 
       # if ossmix is used :) 
    } 
    # bindings are cool. This says, that only the first 
    # two channels are to be used by dmix, which is 
    # enough for (most) oss apps and also lets 
    # multichannel chios work much faster: 
    bindings { 
        0 0 # from 0 => to 0 
        1 1 # from 1 => to 1 
    } 
} 

pcm.dsp0 { 
    type plug 
    slave.pcm "pulse" # use our new PCM here 
} 

# mixer0 like above 
ctl.mixer0 { 
    type hw 
    card 0 
} 

# You may want to make your new ossmix the default for alsa. 
# If your alsa programs are complaining that they can't open 
# your sound devices, try uncommenting this next line 
# pcm.!default pcm.dsp0

pcm.dmixed {
    type dmix
    ipc_key 1234
    slave {
         pcm "pulse"
         buffer_size 8192
         period_size 2048
         #periods 128
         period_time 0
         buffer_time 0
         rate 44100
    }
}


pcm.softvol {
    type softvol
    slave {
          pcm      "dmixed"
    }
    control {
          name     "Master"
          card 0
    }
}

pcm.!default {
    type     plug
    slave.pcm   "softvol"
}

pcm.dsp0 {
    type plug
    slave {
          pcm "pulse"
    }
}

ctl.dsp0 {
    type plug
    slave.pcm "pulse"
}

ctl.mixer0 {
    type plug
    slave.pcm "pulse"
}

 

[CPUnltd]

Packages: (and whatever deps came with them by default)
gst-plugin-pulse
gst-plugin-pulse-dev
pulseaudio
pulseaudio-alsa-wrapper
pulseaudio-dev
pulseaudio-lib-alsa-util
pulseaudio-lib-bluetooth-util
pulseaudio-lib-cli
pulseaudio-lib-dbus-util
pulseaudio-lib-oss-util
pulseaudio-module-alsa-card
pulseaudio-module-alsa-sink
pulseaudio-module-alsa-source
pulseaudio-module-bluetooth-device
pulseaudio-module-bluetooth-discover
pulseaudio-module-cli
pulseaudio-module-oss
pulseaudio-module-udev-detect
pulseaudio-module-zeroconf-discover
pulseaudio-module-zeroconf-publish
pulseaudio-server

 

[torpor]

To get ALSA working properly you'll need the sndloop driver. With this, you can solve all your ALSA problems and (rightly) abandon the futile and purile piece of garbage known as pulseaudio, which I hate with the fire of a million suns.

Ahem. Anyway, yeah. The sndloop driver will allow you to set up multiple 'loopback audio' devices that can be properly connected to create a 'virtual audio interface' that can be bound to bluetooth ..

The problem with the current, default ALSA setup, is that its 'monolithic' - there is only one audio interface (no loopback 'aliases') and so the main ALSA driver is keeping the device held. Its a 'singleton' kind of single-audio-client-at-a-time situation.

But with judicious use of sndloop, this problem can be solved and the existing ALSA config can become multi-client.

EDIT: Its called aloop (I've known it as sndloop since it was on vinyl), actually, more details here:

http://www.alsa-project.org/main/index.php/Matrix:Module-aloop

.. and here:

http://www.linuxmusicians.com/viewtopic.php?f=19&t=2636&st=0&sk=t&sd=a&sid=c5bb421ab555cf971e663fba878f67e2&start=15

.. and more HERE:

http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge

 

[peelie]

To get ALSA working properly you'll need the sndloop driver. With this, you can solve all your ALSA problems and (rightly) abandon the futile and purile piece of garbage known as pulseaudio, which I hate with the fire of a million suns.

Ahem. Anyway, yeah. The sndloop driver will allow you to set up multiple 'loopback audio' devices that can be properly connected to create a 'virtual audio interface' that can be bound to bluetooth ..

The problem with the current, default ALSA setup, is that its 'monolithic' - there is only one audio interface (no loopback 'aliases') and so the main ALSA driver is keeping the device held. Its a 'singleton' kind of single-audio-client-at-a-time situation.

But with judicious use of sndloop, this problem can be solved and the existing ALSA config can become multi-client.

EDIT: Its called aloop (I've known it as sndloop since it was on vinyl), actually, more details here:

http://www.alsa-project.org/main/index.php/Matrix:Module-aloop

.. and here:

http://www.linuxmusicians.com/viewtopic.php?f=19&t=2636&st=0&sk=t&sd=a&sid=c5bb421ab555cf971e663fba878f67e2&start=15

.. and more HERE:

http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge

hi torpor

anychance you could post instructions on how you got this working on pandora?
cheers!

 

[peelie]

does this package work anyone know?
http://www.angstrom-distribution.org/repo/?pkgname=kernel-module-snd-aloop
edit/
bugger is for different kernel

 

[torpor]

Just download the alsa sources and compile the module on your Pandora .. then follow one of the guides I posted to set up the virtual interfaces needed. I've got no idea how it will work with Bluetooth, but I do know that this will give us a multi-client ALSA, which is whats needed for bluetooth ..

 

[peelie]

hi when i try ./configure it says "please install package with full kernel sources for your distribution"?

 

[torpor]

Oh shit, right.. forgot that I'd already done that. Okay, that part is not easy .. best would be for one of the OE builders (skeezix or DJWillis?) to build the sndaloop driver using their build environment, and then make it available for us .. or, failing that, you could get the kernel sources from OPT, install them, and so on .. ALSA needs them to build the modules, obviously, but its not a simple matter.

Whats really needed is for this sndaloop to be used in the next Hotfix ..

 

[CPUnltd]

sounds like getting pulseaudio to work may be a bit simpler, since I'm sure kernel compilation is not part of the process... technically speaking, I have it working... it's a running process, I just can't seem to figure out why the controls hang... I just can't open the volume control or device chooser, but it IS technically running.

 

[torpor]

Its not a kernel compile thats required, ALSA just needs the kernels sources to build its own modules against .. I'll try and get it built, then, anyway. Pulseaudio is a real dogs breakfast and not worth the effort, imho .. whereas a properly configured ALSA would really be great for the music-making apps side of things.

 

[delete000]

how 'bout jack? any hope of it working on the pandora?

 

[CPUnltd]

there are a LOT of music progs that require pulse and jack... so if real music production software is ever gonna be considered, support for JACK at the least (and likely pulse as well) will be a necessity at some point... I have not yet attempted JACK, but I do know that I've seen it in the Angstrom repos, so it's at least been built against armv7a... just a matter of someone installing and tweaking till they get it working then posting a thread or wiki... not sure you will see it in an official release though, just because it is pretty specific and geared toward a direct crowd (media makers)... but you never know.

 

[torpor]

This is one of the reasons why it would be so nice if the guys who are building the HotFix/OE releases for Pandora would have a public build server that can be used to add tweaks to the OS releases after the fact .. The ALSA sndloop module would be really easy to build if we had access to the original OE tree where the Pandora releases are being built in the first place, but from my understanding its a privately installed OE tree, with some Pandora-specific tweaks (DJWillis? Skeezix?) that haven't made it out there yet ..

Jack *would* be useful, as would the full ALSA tree release, with related tools.. I think these are provided in OE, but haven't been included in the Pandora release because of firmware size requirements.

 

[CPUnltd]

if what you say is true, my first and only question is: Why is this not made public in an "Open" project? That kinda rubs me the wrong way. It's not like the info would fall into the "wrong hands" or something... Just my honest thoughts about your statement...

 

[torpor]

It just hasn't been a priority for the volunteers. I think the core OS team are pretty flexible and have done a superb job, but things like Audio optimization in the base OS haven't been a priority for them. Yet.

For my part, I've always had a hard time keeping up with them in terms of the customizations/tweaks to the PandoraOS that have been done. I'd really like to optimize the hell out of the audio subsystem in the Pandora, but it hasn't been easy to do it when I have to build OE and play catch up with the kernel tweaks/patches that are floating around.

But I'm sure this is something we can resolve in the future OS releases.

 

[notaz]

This is one of the reasons why it would be so nice if the guys who are building the HotFix/OE releases for Pandora would have a public build server that can be used to add tweaks to the OS releases after the fact .. The ALSA sndloop module would be really easy to build if we had access to the original OE tree where the Pandora releases are being built in the first place, but from my understanding its a privately installed OE tree, with some Pandora-specific tweaks (DJWillis? Skeezix?) that haven't made it out there yet ..

That's bs. Where did you get this "information" from?
The build server pulls everything from public git trees, same old DJWillis scripts are used for this:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-oe-environment.git;a=tree

Now somebody thinks we are hiding sources, please stop misleading people.

 

[torpor]

I don't think you're hiding sources, notaz, but its been stated to me at times while investigating audio issues in PandoraOS that there are some things that haven't traditionally been included in the tree .. kernel tweaks, etc. If that is no longer the case, then I am glad to know about it and I will have to try to update my OE tree to match that of the PandoraOS as it is currently built ..

That said, any chance snd-aloop.ko can be included in the next release?

 

[chris_c]

gods no - what a terrible thing to do to an embedded platform, add latency and use buckets of precious memory - for very little or no gain.

I cannot think of a piece of software that can't use something else other than pulse so why bother?

besides what more do you need than milky tracker (j/k)


Lets just hope this little experiment doesn't make it onto the "official" firmware...

 

[CPUnltd]

I'm curious... exactly what part of what has been said do you not want to see in the firmware, chris? Rather not assume and choose to actually ask.