Pyra Audio Library?


pmprog

DNF (Did Not Finish)
Joined
Apr 25, 2011
Messages
4,150
Is the Pyra using PulseAudio? Or JACK? ALSA?
I've finally ordered me a usb 4g modern from aliexpress that I'm hoping to use with a Raspberry pi to start looking at writing some phone software, so i was wondering what i needed to setup up to closely match the Pyra that i can
Cheers
 
Install Debian Stretch, use what is installed by default. ( PulseAudio )
 
Thanks.

Edit: Seems Raspbian have removed PulseAudio from their Stretch distribution...
 
Last edited:
If in doubt, always choose ALSA as a target. Aside from OSS (the real deal, not the in-kernel emulation!), everything else is just built on top of ALSA anyway - and PulseAudio uses a custom ALSA plugin to reroute audio streams of programs using ALSA to itself. It is simply the most compatible choice. You can still add in support for other APIs later on.
 
From a vaguely related OMAP 4 document I've stumbled upon while searching for the answer to this, ABE is the audio backend, a kind of driver. And AESS is described by this slightly circular set of definitions:
AE : Audio Engine, part of the AESS. Makes the signal processing operations
AESS : Audio Engine Sub-System, part of ABE. Includes AE, ATC, timers and clock control
ATC : Audio Traffic Controller. Makes the data move between the DMEM and peripherals
DMEM : Data memory, part of the AE. Used to control the processing and do data moves with ATC.

Make of that what you will. Note the slight difference in capitalisation between ATC and our own aTc.
 
Last edited:
Fair warning it's been a while since I've done this stuff, or researched options, so take my advice with a grain of salt.

If you wanted to make your life easier, I would say use SDL, or OpenAL. Both of those libraries allow you to hook into a sound back-end pretty easily and let you focus on just pushing sound through in a consistent fashion.
SDL is capable of producing graphics without an X11 server as well, so you can use it to make a gui just using a framebuffer.

As heavy as it sounds, you may also want to consider using a game engine or framework for your project. Those generally have support for multiple backends, and can provide a framework to make an interactive interface.

Otherwise if you want to keep things simple, yes writing your code to talk to Alsa is a good call. If pulse audio is installed, it's can show up as an Alsa device to your software, so in theory you don't have to explicitly program for Pulse Audio. (Though there's probably good reasons to make your code aware of it).

Something like Pulse Audio (or Jack) being your sound server allows you to easily switch your audio streams from HDMI, to Analogue Out, to a Bluetooth headset, all without your application even knowing that the input/output devices have changed. So generally your application doesn't need to be explicitly aware of all sound input and output device options, or where sound it going. Though that is always a nice feature to provide when doing something like Phone software.

I've seen quite a few projects that end up supporting Alsa, Jack, and PulseAudio, along with providing SDL and OpenAL. There's no need for you to go quite that deep, but it does make me wonder if there are some existing convenient libraries out there to make it easy for you to handle a wide variety of sound servers. (or it could be a feature of just using OpenAL or SDL).

There could be some other sound libraries out there, but that's what I'm aware of.
 
Something like Pulse Audio (or Jack) being your sound server allows you to easily switch your audio streams from HDMI, to Analogue Out, to a Bluetooth headset, all without your application even knowing that the input/output devices have changed
That's mostly why I was looking at using them.

SDL is capable of producing graphics without an X11 server as well
I was thinking of Qt, but being able to support non-X11 might be worth the consideration.

I'm still awaiting my USB modem, apparently it can arrive anywhere up to 20th December or something daft, though I guess there's no reason I can't start work on the GUI.

It'd be nice to see if an M4 core could be used for the monitoring of the modem, then trigger the application on the main system... but that can go further down the pegging order
 
On a side note, the Gnome guys started working on PipeWire, which is planning to replace both PulseAudio and JACK while even providing the means to use it as a drop-in replacement.

Sounds like an almighty Swiss army knife with all of the advantages but none of the drawbacks - and a full set of entirely new features, it was actually created to stream videos.
 
Pulseaudio itself was a drop in replacement for ESD, I read, so things can be replaced that way I tend to think.

It may be worth noting that this Pipewire thing apparently won't support network transparency out of the box; that functionality will likely be in a separate library. That's the thing I always though was special about pulseaudio before I started using it, although I actually started using it when I discovered playing back audio on my laptop used less CPU if piped through pulseaudio rather than through ALSA. If Pipewire can't do that I'm unlikely to start using it.
 
Pulseaudio itself was a drop in replacement for ESD, I read, so things can be replaced that way I tend to think.
It still used its own API instead of actually building on top of it, though. ESD compatibility was realized through a loadable compatibility module - do they even still support it?

It may be worth noting that this Pipewire thing apparently won't support network transparency out of the box; that functionality will likely be in a separate library.
They move pretty much everything not directly related to its core functionality into separate libraries. Its core is all about moving multimedia streams around in a dynamic fashion, it was actually created to fulfil the additional needs of FlatPak and Wayland - all it takes to get network transparency is wrapping everything up in an IP friendly way. Actually, you should even be able to do this entirely through GStreamer as PipeWire directly interfaces with it.

I do hope they do it right, PulseAudio's module system is a horrible unusable abomination.

when I discovered playing back audio on my laptop used less CPU if piped through pulseaudio rather than through ALSA.
Actually measuring that is not that easy, though - due to the decentralized design of ALSA you don't have a separate process doing the actual work. Some programs may simply react differently when providing the dmix instance that handles the mixing for the whole session. In the end the reason could as well just be that PulseAudio defaulted to a more lossy resampling algorithm to achieve that - both can be configured to use a different resampling algorithm.

My experience was more the other way round, PulseAudio has always been a CPU hog for me.
 
I've yet to see an 'ideal' software audio mixer interface.

Just give me a spreadsheet looking table. Inputs down the left column, each output across the top row, % of max output in each cell. Touch a cell to adjust it's volume with a big knob or slider overlay that goes away when done.

Inputs? Any program creating sound OR any input sound device (including mic, USB port audio inputs, bluetooth mics...)
Outputs? Any target - or even all of them. Speakers, headphone jack, bluetooth, USB device audio, audio capture programs...)

Why? A true mixer such that any inputs can be mixed together to supply discrete mixes to any output. Pyra as professional mixer for recording or live performances.

XLR to USB mic input adapters. Likely up to a dozen mono inputs via the USB 3.0 OTG in host mode with a hub.
USB outputs to monitors. 2 stereo outputs easy through each of the USB 2.0 ports. Likely upwards of 8 stereo outs by using a pair of 4 port USB 2.0 hubs.
Theoretically should be able to run in wireless mode - be the connection point for WAN mics & IEMs.
Operator can monitor any output, house mix or special via the headphone jack AND be able to communicate back via stage or in ear monitors via the mic on his/her headphones.
Backing tracks easily run from any of the device storage options.
Continually powered via microUSB with on-mixer battery backup.
Flexible mix of inputs and outputs.

Version 2.0
Network each musician's personal Pyras together so that each can see & adjust their own mix to their IEMs and see & adjust their own effects loop all networked to the 'main' that runs the house PA.

I can dream right?
 
My 4G modem stick has arrived, but I can't seem to find any "audio" devices. It just seems to create a single ttyUSB device; so at the minute, I have absolutely no idea what to do with it.
 
Those modems usually come with the call feature deactivated. You probably have to activate it either in their software UI or with AT commands you send into the ttyUSB.

Last time I played with a modem like that (a 3G one) i had to do a firmware update to be able to activate voice, and IIRC after i activated it with AT commands it stated showing up an additional ttyUSB.
I was able to confirm it was for audio as it showed jargon in the console when I a attempted a call but i was never able to find out what kind of format the audio was in.
I think some time after I was able to make audio work with asterisk with some weird module that was no longer maintained at the time and I never found the source code for.

Sorry for the vague information but it was a long time ago. I would also like to help you with that as I think I still have that modem somewhere but unfortunately I have absolutely no time right now.
 
Thanks. I did wonder if the audio devices were created after I "picked up the line", but in all honesty, I've not spent a great deal of time with the device. I need to spend some proper time with the device looking into it, but knowing my record, it'll probably just end in a drawer
 
Back
Top