Making Pandora's Speakers Sound Better


Esn

(:";
Joined
Mar 5, 2003
Messages
3,239
Location
Toronto, Canada
Website
esn.newgrounds.com
While the Pandora has excellent sound if you use headphones, the speakers leave much to be desired, especially where balance is concerned. There seems to be a strong midrange, weak high range, and even weaker low range. I wonder if there's any way to compensate for that by boosting the high & low frequencies in Xfce.
 
this is probably related to ALSA's poor implementation (no offense to whoever set things up, but I'm not gonna lie about it)...
 
It's not just the Pandora, that appears to be how Angstrom has it set up across everything. I've no idea how to fix it. Tried installing PulseAudio and it just made things worse. :(
 
still looking for good info on how to implement pulseaudio around these parts... Not sure if it's a hardware thing or a software thing, because the .asoundrc file is the most complex I have ever dealt with. And the system won't accept a simple .asoundrc like a copy/paste job from a standard PC. Of course, it could be a driver/module issue (which is said to be one of the things possibly getting addressed in HF6... but we shall see...
 
Custom Processing Unlimite said:
Not sure if it's a hardware thing or a software thing
It's a software thing. Where most other implementations of Alsa have a fake OSS driver, the one in Angstrom is a daemon that wraps itself around OSS. It's just bad, and I've no idea how to fix it.
 
Last edited by a moderator:
start from scratch... there's gotta be SOMEBDOY around here that knows about ALSA well enough to fix this. hmm... I'd think it should be a simple as adding the necessary ALSA bits, removing the UNNECESSARY OSS bits, configuring ALSA and calling it a day... But I haven't seriously looked into this yet. Also, where do I go to see exactly what it run at boot? I'd be willing to play around with my SD install again so I can get this working right... it's killing me in a FEW ways (namely, Linphone usage, for one!)... But I don't know Angstrom well at all and their documentation is not on the same level of Arch Linux, so it's a curve that I'm not used to just yet. (plus lack of time :p)
 
WizardStan said:
Custom Processing Unlimite said:
Not sure if it's a hardware thing or a software thing
It's a software thing. Where most other implementations of Alsa have a fake OSS driver, the one in Angstrom is a daemon that wraps itself around OSS. It's just bad, and I've no idea how to fix it.
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.

The reason why there is no software control is hardware, the DAC is not programmable at all, as well as amplifier, which can only be controlled by volume wheel. The volume control you see in XFCE is an ALSA plugin ED added which adjusts volume of audio stream before sending it to hardware. Maybe similar plugins can be set up to adjust frequencies, I don't know.
 
Last edited by a moderator:
@ notaz:

If it were true that the ALSA driver was full-on, why is it so hard to get a working basic configuration? Also, why is it essentially impossible (at this point) to implement pulseaudio? Memory hog or not, I have never had to work hard to wrap pulse around ALSA and I've dealt with it on at least 3 distros before using it on the Pandora. Also, none of the options I've played with in .asoundrc from ALSA's own website seem to function at all. I've only been able to get ALSA working by leaving it alone with it's default settings (which only handle one audio stream at a time and someone in my pulseaudio thread -forgot your name, sorry- mentioned that kernel modules were missing or needed to be rebuilt to support multi-stream audio... so the implementation of ALSA for the Pandora is, by no means, real or complete by my comprehension.

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)... I could be wrong. Maybe it's one of those things that's picky due to the hardware and just hasn't been figured (hammered) out. But I do know that the implementation of ALSA around these parts is not close to the same as anywhere else I've been.
 
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.
 
Last edited by a moderator:
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 ..
 
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.
 
Last edited by a moderator:
notaz said:
I'm in the same position as you, they don't even list me part of the team on the other forums.
This rather shocks me, to be honest.

Anyway... I really don't understand the technical details, so I'll just ask: what would be required in order to make it possible to add an option in the Pandora's mixer controls to boost low & high frequencies by certain amount when headphones are not plugged in so as to compensate for the sound quality of the speakers (or, alternately, dampen the mid-range frequencies which sound abnormally loud)?
 
Last edited by a moderator:
notaz: snd-aloop.ko will help with, for example, pulseaudio configuration .. a loopback audio device pair can be created for routing pulseaudio data independently from ALSA/OSS devices, meaning all three can co-exist without biting each other in the ass. We can also set up snd-aloop aliases for multi-client ALSA apps, so that I (for example) could release a PND with multiple ALSA-output synthesizers in it, each one going to their own ALSA alias, and thus having an 'audio mux' situation happening ..

EDIT: for the /dev/dsp situation, clients that cannot be modified to use a properly configured aloop alias could, instead, be run in a chroot, where the chroot /dev/dsp is actually (outside the chroot) configured to be just another snd-aloop alias .. this would provide co-existence between OSS and ALSA apps.

EDIT2: Notaz, you said:

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.

Ah hah, that is true that it did not appear in the ALSA (kernel) sources until 2.6.36! BUT: it can be compiled and built from the ALSA standalone sources as an external module!

http://www.alsa-project.org/main/index.php/Matrix%3AModule-aloop

(see the bit about ./configure --with-cards=aloop --with-sequencer=yes ; make ; make install)

EDIT3: Wanted to add this nice thread that gives an example of how snd-aloop can be used to de-thorn sticky audio problems:

http://www.linuxmusicians.com/viewtopic.php?f=19&t=2636



Now .. I'm with you that it is a *lot* of work to get Linux audio working properly, and I don't want to give you the idea that I am critical of this work - mostly I just with to report what I have found/what I think about the existing situation. I am in no way critical of your work.

The thing is, really, I haven't had the chance to get a fully-working OpenPandora development environment (OpenEmbedded/Angstrom with Pandora flavours) set up, or else I'd see what I can do about the backport. It would be really, really beneficial, if we had a common community build server somewhere that trusted users could access, in order to not have to keep doing the same old bitbake work to get things like the root file system for the releases built, and so on. I know its been discussed before, but if I could access a build system that already has the main filesystem and packages build on it, I could more easily help work in integrating solutions for the audio subsystem.


Anyway... I really don't understand the technical details, so I'll just ask: what would be required in order to make it possible to add an option in the Pandora's mixer controls to boost low & high frequencies by certain amount when headphones are not plugged in so as to compensate for the sound quality of the speakers (or, alternately, dampen the mid-range frequencies which sound abnormally loud)?

This is a lot of work, to be honest. I think there are layer problems here - we have to get the lower-layers (ALSA/OSS/Pulseaudio) integrated properly to support such user features higher up the chain. If we can get ALSA/OSS/Pulseaudio co-existing properly then a Pulseaudio module for handling the EQ in the above scenario would be more feasible. Another option is to "do it in the audio client", which is (imho) where the EQ belongs in the first place. Audacious has an EQ .. tried it?
 
torpor said:
Another option is to "do it in the audio client", which is (imho) where the EQ belongs in the first place. Audacious has an EQ .. tried it?
Yes, but I'm thinking about music in emulators also.
 
Last edited by a moderator:
Well in that case, Esn, an alsa EQ plugin could be used .. but this requires a bigger build-out of the audio system than we've currently got.
 
Alerino said:
Esn said:
notaz said:
I'm in the same position as you, they don't even list me part of the team on the other forums.
This rather shocks me, to be honest.

I know motivation is a personal thing, but notaz, you are a hero among pandora users, you shall not forget that.
:)

edit: from the official page => "The Pandora wouldn't rock as much without him!" Cheer up, you rock!

notaz, skeezix and WizardStan all deserve our thanks. I for one have not forgotten the work that has gone into the firmware, and I thank all of you again for it!
 
Last edited by a moderator:
notaz said:
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.
Didn't quite get it working. It locks up at some point trying to start X. I need terminal output to figure out what it is doing wrong. The EXT connectors I've got coming will help with that.

notaz said:
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.
Sorry, I didn't mean to imply any incompetence, just looking for easy answers: it behaves the exact same way on my BeagleBoard, so I took it as a sign of Angstrom's implementation, not something that you specifically were or were not doing. All respect to you, honest, you're far more knowledgeable about these things than I am. You're right, I didn't start using Linux until about 2004, but over the years I've experimented and broken some stuff, even had to fall back on pure OSS when my ALSA drivers were failing. I'm aware of the history of OSS and that it was single stream only. I'm also aware that even before switching to Pulse, the OSS emulation in ALSA on my desktop was mixing multiple streams with no problem. Sorry, I've been using it so long I just assumed that that was the default, and that it was Angstrom's implementation doing something bizarre, not the other way around. It honestly didn't occur to me that there would be different OSS emulation options, it just seems like the kind of thing that would be easy to standardize, but I can understand now why that's not the case.

David Bowman said:
notaz, skeezix and WizardStan all deserve our thanks. I for one have not forgotten the work that has gone into the firmware, and I thank all of you again for it!
I don't deserve anything yet. Absolutely none of my work has actually made it into the firmware yet, and what I've got is pretty simplistic compared to the amount of work notaz and skeezix have done.
 
Last edited by a moderator:
Alerino said:
hey you Wizard, don't diminish your importance here. You and Prometheus do a terrific job everyday helping out the new users, and best of it, free of charge, just because you guys, like myself, wanna make Pandora a very enjoyable device.

well said
 
Last edited by a moderator:
torpor said:
EDIT: for the /dev/dsp situation, clients that cannot be modified to use a properly configured aloop alias could, instead, be run in a chroot, where the chroot /dev/dsp is actually (outside the chroot) configured to be just another snd-aloop alias .. this would provide co-existence between OSS and ALSA apps.
Yeah but that's a bit painful to do for every emu out there.. Also maintaining separate chroot on NAND.

torpor said:
EDIT2: Notaz, you said:

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.

Ah hah, that is true that it did not appear in the ALSA (kernel) sources until 2.6.36! BUT: it can be compiled and built from the ALSA standalone sources as an external module!
I guess so, still needs work to set this up in OE.

torpor said:
The thing is, really, I haven't had the chance to get a fully-working OpenPandora development environment (OpenEmbedded/Angstrom with Pandora flavours) set up, or else I'd see what I can do about the backport. It would be really, really beneficial, if we had a common community build server somewhere that trusted users could access, in order to not have to keep doing the same old bitbake work to get things like the root file system for the releases built, and so on. I know its been discussed before, but if I could access a build system that already has the main filesystem and packages build on it, I could more easily help work in integrating solutions for the audio subsystem.
Well giving access to main build server doesn't look like a good idea as some unintentional "oops" mistake can break it and we loose the ability to build firmware. We already are very low on firmware developer resources, so things like that would just make already rather miserable matters worse.

The problem with OE is that it's very OS dependent and needs hundreds of gigabytes of space for it's stuff, so just tar'ing up working setup and uploading somewhere is not really an option. Making a server for community again has it's problems, not only hardware resources are needed but also someone looking after it, giving users access and fixing it all up if someone screws up (intentionally or not).

After thinking about it I came up with idea of making a tested Linux VM with all the OS dependencies setup. So you basically free up 300GB or so, download a VM image, load in under kvm/virtualbox/whatever, fire up a build there and it makes you a firmware image from start to end, without user interaction (would take a couple of days but whatever). What do you think?

WizardStan said:
I don't deserve anything yet. Absolutely none of my work has actually made it into the firmware yet, and what I've got is pretty simplistic compared to the amount of work notaz and skeezix have done.
I'll try to make sure to merge your stuff for the next hotfix.
 
Last edited by a moderator:
Back
Top