... we're still alive!


You should not expect to be able to use it in games.
Recently, I played Kaboom on my Atari 800XL with a paddle. The precision you need is not doable with a volume wheel. From min to max, on the Atari, there are 229 values. You can not get this resolution with such a tiny wheel.
Practicality isn't the point (plus I may get better with practice). I play FPSs on my Pandora with the built in gaming controls often enough, and that is a very poor choice, as well.

Like levi said, it is mainly a "because I/we can" thing.
 
Last edited:
Wait, so the value in your device, is that other people can't do something with their own devices?

Spoken like a person who never used a GP2X. When you make the volume control through software, people have to support it for it to work. That's why plenty of games for the GP2X forced you to go into menus to change the volume, or worse: didn't even allow you to change the volume in game. You had to literally exit the game, change the volume, and then start the game again for those. This exact problem can arise on the Pyra if people try to use other images like they did on the Pandora. (Android, Arch, etc.) Because they will have to support the volume wheel rather than it just working.

-God Ginrai
 
Spoken like a person who never used a GP2X. When you make the volume control through software, people have to support it for it to work. That's why plenty of games for the GP2X forced you to go into menus to change the volume, or worse: didn't even allow you to change the volume in game. You had to literally exit the game, change the volume, and then start the game again for those. This exact problem can arise on the Pyra if people try to use other images like they did on the Pandora. (Android, Arch, etc.) Because they will have to support the volume wheel rather than it just working.
Yes, your OS needs to support your hardware. That's to be expected.
 
Yep, the gp2x didn't have any daemon running, that's why it didn't work if the game didn't support it.
That has nothing to do with the Pyra though.
 
But on Pyra the custom/community OSes will have to reimplement the daemon again and again and again...
Which is probably the most important thing one has to worry about when its about adapting another distro to the Pyra, because everything else (gfx, controls, etc.) will work out of the box.

Whats the meaning of this ? Give ED a break, that thing is done, nothing to change about that anymore. So could we just move on instead of vividly running in circles (again) ?
 
You always need some Pyra customizations for other OSes. You need to load the keymap layout (easy to do, I know), probably include scripts for properly setting up nubs, etc.
It shouldn't be hard to add that daemon as well. And ignore it and use the software sliders included.

On my desktop PC, I always use the software volume sliders, as the home stereo is too far away.
 
You always need some Pyra customizations for other OSes. You need to load the keymap layout (easy to do, I know), probably include scripts for properly setting up nubs, etc.
It shouldn't be hard to add that daemon as well. And ignore it and use the software sliders included.

On my desktop PC, I always use the software volume sliders, as the home stereo is too far away.

i will eventually end up with removing pulseaudio/daemon and using pure alsamixer via the keyboard.
i like things to be easy and don't have a need for different volume-settings. pulseaudio made me really mad
back in the day, changeing my set volume. maybe it's better now, haven't used pa for a loong time, but
i will stay with simple alsa, i think.

ps. down with systemd, too! ;)
 
i will eventually end up with removing pulseaudio/daemon and using pure alsamixer via the keyboard.
i like things to be easy and don't have a need for different volume-settings. pulseaudio made me really mad
back in the day, changeing my set volume. maybe it's better now, haven't used pa for a loong time, but
i will stay with simple alsa, i think.

ps. down with systemd, too! ;)
No reason the volume wheel can't work with good old ALSA and SysV init. :) (I'll be doing the same probably.)

(FYI, per-application volume settings is also possible with plain ALSA, but a bit more complex.)
 
@rSl back when I didn't know what I was doing I ran into sound issues that were beyond my skills at the time to sort out. I thought it was due to pulseaudio. This delayed my fully embracing Linux back then, since I didn't understand all the issues that were being caused (I just thought sound was unstable due to the nature of open source) and I assumed my hardware wasn't supported. I do still hold a grudge (I wanted Linux so that I could play with *nix at home). When I found out the guy behind it was pushing more stuff that was messing up Linux I was not happy with that. Sure, I will work with systemd if I am being paid (just like Windows), but I still don't know what I am doing, despite taking two classes that I thought would help me out.

Since pulseaudio doesn't seem to cause me so many problems anymore I will probably stick with it.

I will use the default Debian for many things, along with trying out various other options with the microSD. I like that the Pyra will give us so many ways to play around with such things.
 
Last edited:
  • Like
Reactions: rSl
I mostly like systemd (there are a couple of parts with annoyances, but generally it's been nice) and have recently found a liking to pulseaudio as well. A week or so ago I needed to pipe sound from an application to a browser-based video chat along with my mic input. Was surprisingly simple to set up with PA. I had enough issues with PA back in the day that I used to just purge it if it came preinstalled, but nowadays I install it if it's missing.
 
  • Like
Reactions: rSl
I mostly like systemd (there are a couple of parts with annoyances, but generally it's been nice) and have recently found a liking to pulseaudio as well. A week or so ago I needed to pipe sound from an application to a browser-based video chat along with my mic input. Was surprisingly simple to set up with PA. I had enough issues with PA back in the day that I used to just purge it if it came preinstalled, but nowadays I install it if it's missing.
I'm still not at that stage yet. On debian stable, pulseaudio is still giving me trouble on a daily basis on the one machine I have it installed on.
 
I'm still not fine with systemd but I also had an improvement thanks to PulseAudio on a headless server at home. I was using mpd with a USB DAC/soundcard. Sometimes I disconnect the USB device to listen with my helmet in my bed or during a trip (it is nicer than integrated audio). When reppluging the device to the server, I don't need to do anything with pulseaudio, it just works. With ALSA, I used to have to restart mpd.
 
Last edited:
I'm using PulseAudio for years on various Linux machines and love it.
Of course, if all you need is one master volume control, it's overkill, but if you are doing multitasking and want to change the volume of only one program, it's incredibly convenient. Or route music to your stereo while still getting email notifications only on your laptop.

Also, simply choosing whether you want your sound routed through HDMI or your speakers is also easily doable.

If you do stuff like that, it's great! With the Pyra, you could play a game with sound on HDMI while someone else listens music via the headset port and new emails could be announced through the speakers...

So yes, whether pulse is useful or not depends on your use case.
 
That seems useful if we get cellular capable Pyras. I could listen to music through my headset, and incoming messages wouldn't interrupt the song. It should also help if the Pyra is used as an alarm clock (since games and such can have a different volume level than the alarm clock).
 
I mainly notice pulseaudio when it randomly changes the output volume for a program, requiring me to open pavucontrol to restore it. And it happens just about every time a new output stream is opened.

I had that problem too, solved by editing "/etc/pulse/daemon.conf" and changing this line "flat-volumes=no"
 
Back
Top