0

I have a project that I am working on, for the purposes of this question, lets say they are wireless speakers.

We are using the raspberry pi for development right now but we plan to move to our own embedded solution. The codec we've chosen fits our needs best, although it isn't an "ALSA supported" codec. As in the ALSA webpage doesn't have info on it.

Much of the PCM code I've found to develop this on the raspberry pi use ALSA streams. Is it a standard to use an ALSA codec for these types of projects?

I haven't worked much with embedded linux or RTOS. I work with bare-metal systems quite frequently though which explains my confusion on what ALSA exactly is. It seems like some odd middleware or something.

Funkyguy
  • 628
  • 2
  • 10
  • 31
  • What exactly are you trying to build? Are you generating audio data you hope to play? Building a remote alternative to a sound card? – Chris Stratton Oct 23 '14 at 17:37
  • @ChrisStratton I'm trying to make wireless speakers. I am not generating the audio, it is being sent to me over a connection using the RTP protocol. – Funkyguy Oct 23 '14 at 19:56
  • Then this is all irrelevant - use whatever works with the hardware of the receiver you build - it will be internal detail invisible to the source end of the RTP connection. – Chris Stratton Oct 23 '14 at 19:58
  • @ChrisStratton Okay, I'm only confused because it looks like PulseAudio uses ALSA and I can't find any documentation on using my own sound driver – Funkyguy Oct 23 '14 at 20:00
  • What problem are you trying to solve? The Receiving end? Or do you want to give an interface to the remote sourcing end, which clients can put audio into in order to have it shipped over the RTP pipe to your speakers? – Chris Stratton Oct 23 '14 at 20:02
  • @ChrisStratton The receiving end. PulseAudio has a module called module-rtp-recv and I feel like I could make use of that but I'm having a hard time making the bridge between RTP and the low level I2S driver. I've never done anything with streaming protocols. – Funkyguy Oct 24 '14 at 04:25
  • One big thing you will have to decide is if the receiving system will route this as "audio" through some portiins of an audio stack, or merely as custom data. A bigger issue is if you can slave the playback clock to the stream, or if you are going to have to compensate for *inevitable* difference between the source and an i2s clock derived from a local crystal. – Chris Stratton Oct 24 '14 at 11:21

1 Answers1

0

ALSA is

  • the API that application that want to use sound use; and
  • the library that implements this API; and
  • the interface between this library and the kernel; and
  • the kernel implementation of this interface; and
  • the framework to be used by sound drivers.

To have your codec supported in Linux, you must write an ALSA driver.

CL.
  • 173,858
  • 17
  • 217
  • 259
  • Correction: ALSA is "one" method... but not "the" only one. Pulse is another common one. And yes, there are ugly emulation cases of one substituting for another, too. – Chris Stratton Oct 23 '14 at 16:55
  • @ChrisStratton There are no PulseAudio sound drivers; PA always uses ALSA drivers. – CL. Oct 23 '14 at 17:05
  • No, Pulse does not always use ALSA drivers - it can run on OSS and on non-linux operating systems. More relevant to the point, ALSA is not the only API a **userspace** developer can choose to target (though it is indeed the one I've tended to choose for simple tools) – Chris Stratton Oct 23 '14 at 17:08
  • But the only usable framework to write the codec driver is ALSA. – CL. Oct 23 '14 at 17:30
  • Then how else would you be able to write a codec driver? – CL. Oct 23 '14 at 17:33
  • Which one? Please name one that would work in this case. – CL. Oct 23 '14 at 17:38
  • I already named two. But the choices are actually infinite, because one can do something custom as well, and back end it to the others. Or front end it. The poster is yet to state an answerable question. – Chris Stratton Oct 23 '14 at 17:40
  • I'm not exactly looking for "linux support" since we are moving to a different embedded solution later. We probably won't be running on linux in the end but a more low-level OS. There is the possibility of a much smaller version of linux but we haven't discussed that too much. Does this help? – Funkyguy Oct 23 '14 at 19:58