Custom Processing Unlimite said:
If it were true that the ALSA driver was full-on, why is it so hard to get a working basic configuration?
Because ALSA itself is pain to work with?
Custom Processing Unlimite said:
Also, why is it essentially impossible (at this point) to implement pulseaudio?
It is possible, just nobody wants to do it for some reason. Personally I have no interest in pulseaudio. Hasn't WizardStan said above he had it working? Maybe he could share some info how to get it up.
Custom Processing Unlimite said:
The software volume control is neither here nor there as far as I'm concerned. What it all boils down to (in standard Pandora usage) is that I can't play my favorite fight song list while mutilating people in Street Fighter (insert number here)...
This problem has little to do with ALSA driver, this is because the programs you use are using OSS interface, and default ALSA's OSS emulation doesn't allow multiple streams when used this way.
Custom Processing Unlimite said:
But I do know that the implementation of ALSA around these parts is not close to the same as anywhere else I've been.
Let me reiterate, it's not how ALSA itself is setup, it's about how OSS emulation is set up. In PC world OSS is being phased out, on pandora it's used a lot due to legacy reasons (GPH devices only have OSS, many emus came from there).
WizardStan said:
notaz said:
I don't know where you people get information like this. Pandora uses real ALSA driver with OSS emulation enabled for GP2X ports and such.
If this were true, then opening the OSS device wouldn't block all ALSA programs, and those programs that do output to OSS would use whatever ALSA has setup as its output, instead of always playing on the speakers: only programs that actually use ALSA can be made to output to bluetooth.
edit: further evidence that it is Alsa layered on top of OSS (instead of an OSS wrapper within ALSA) is that mplayer output to OSS is faster than to ALSA. It should be the other way around, if anything.
Hell WizardStan, do I have to remind you I was unfortunate enough having to deal with all those drivers? Are you trying to imply I'm not competent enough to know what I did? And your "further evidence" only shows your lack of knowledge really.
Pandora is using default kernel-side OSS emulation, which can only deal with single stream (read more
here). I suppose you weren't using Linux sometime like 2002 when it was a big deal, basically there were lots of OSS programs and only one could be used at a time.
The reason why OSS is faster is because ALSA's OSS emulation bypasses dmix, the software mixing part, which is used if you play sound through ALSA interface.
Alternative OSS emulation options exist, but AFAIK they haven't been test much on pandora (if at all). I can tell you messing with ALSA is no fun, or with Linux audio in general for that matter. You can blame my work as much as you like, but there hasn't been anyone else wanting to go through all that pain. I'm not saying the current setup is best possible (it surely is not), feel free to come up with better setup. I'm in the same position as you, they don't even list me part of the team on the other forums.
torpor said:
We really, really, really .. really .. need snd-aloop.ko to fix all ALSA/OSS-related sound issues.
Without it, its practically impossible to set up multi-client access to the Sound devices. With it we can add multiple virtual audio devices ..
And how is that supposed to help OSS emulation? Many programs expect to write to /dev/dsp, virtual devices will not help (feel free to prove me wrong). I can easily get that module included for the next hotfix, but I don't believe it will help things.
Edit: no I can not, it only appeared in 2.6.36 so will need to wait for kernel upgrade or someone doing the backport.