Moving from OSS to ALSA

Moving from OSS to ALSA

[James Wright]

Hello,

   I am currently looking into rewriting our current OSS sound routines to native ALSA, as it seems OSS will invariably be phased out now that the ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a great number of benefits for us. 

  Our current sound routines perform software sound sample mixing for use in games. All the  mixing and transfers happen in a non-blocking function called update_jsound() which we call every 1/60th of a second in our main game loop. We find the total size of the hardware ring buffer and use MMAP writes to it. We effectively break the ring buffer into 1024 byte "fragments", and always keep one whole fragment ahead to ensure no underruns. We do this by the follwing:



  ioctl(audiofd, SNDCTL_DSP_GETOPTR, &info);  // get position of DSP pointer

  if (info.ptr >= trigger){ // hit a frag boundary, so write another fragment ahead
      trigger += FRAGSIZE;  // move triggering position to next fragment boundary
      if (trigger >= DMA_SIZE) trigger = 0; // wrap around if at end of DMA buffer
      dptr = DMA_PTR + trigger;  // set write ptr to next fragment

      ...
      mix and write all samples playing into the buffer
      ...
 
      //printf("Ptr position: %u\n", info.ptr);
      //printf("Trigger: %u\n", trigger);
  }


   With all the different methods available the ALSA offers i'm finding it hard to determine the best method to use to do the same job as the OSS code. I have started by writing  a standard "write" access with non-blocking, with a buffersize of 500000 usecs and a period time of 100000 usecs, but i want to know how to determine if there is only one period remaning, which is when i would want to mix and write the next one ahead...

Sorry if this has been covered before...


Thanks,
James






-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[Paul Davis]

>   I am currently looking into rewriting our current OSS sound routines to nat
>ive ALSA, as it seems OSS will invariably be phased out now that the ALSA driv
>er is distrubuted with the Linux kernel, plus ALSA seems to have a great numbe
>r of benefits for us. 
>
>  Our current sound routines perform software sound sample mixing for use in g
>ames. All the  mixing and transfers happen in a non-blocking function called u
>pdate_jsound() which we call every 1/60th of a second in our main game loop. W
>e find the total size of the hardware ring buffer and use MMAP writes to it. W
>e effectively break the ring buffer into 1024 byte "fragments", and always kee
>p one whole fragment ahead to ensure no underruns. We do this by the follwing:

best method:
-----------
1) set the avail_min s/w parameter to the period size
2) call poll on the file descriptor(s) returned from
   snd_pcm_poll_descriptors(). when you return from poll,
   you know you have at least one period of data ready (possibly
   more, so you need to check).
3) use snd_pcm_mmap_*() to handle mmap access. ALSA
   doesn't provide simple access to mmap'ped buffers 
   because this could not work for some classes of
   ALSA devices.

survey the source of JACK (jackit.sf.net) for some ideas.

however, that probably won't work so well for you it doesn't integrate
into your "game loop". for that, use snd_pcm_delay() to find out the
gap between the application (s/w) pointer and the hardware pointer,
then use the snd_pcm_mmap_*() calls from there.

its a lot more complex under ALSA. but thats because ALSA provides a
lot of things that OSS does not, and doing everything via the simple
system call interface that OSS uses makes it impossible to provide
them "appropriately".

if you were writing software for musicians and studios rather than
games and consumer media apps, check out JACK for a different, simpler
and more powerful API (that uses ALSA internally).

--p


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[James Wright]

   Ultimately i think with ALSA we could do away with the concept of calling update_jsound() in the game loop and instead use asyncrosnous mode and use update_jsound() as my callback function? Although i'd need to get ALSA to call update_jsound() when we are in our last period, so we can write another one ahead... any ideas?  

   In the meantime can i not use  snd_pcm_avail_update() to determine if we need to write a period ahead?;

  avail = snd_pcm_avail_update(pcm_handle);
  if (avail >= (buffer_size - period_size)){ 
      mix_sound(MIXBUFFER, period_size);   // mix a period wirth of channels
      ret = snd_pcm_writen(pcm_handle, (void *) &MIXBUFFER, period_size); // write it
  }

  


Many Thanks,
James 


On Sun, 11 Jan 2004 13:28:57 -0500
Paul Davis <paul@linuxaudiosystems.com> wrote:

> >   I am currently looking into rewriting our current OSS sound routines to nat
> >ive ALSA, as it seems OSS will invariably be phased out now that the ALSA driv
> >er is distrubuted with the Linux kernel, plus ALSA seems to have a great numbe
> >r of benefits for us. 
> >
> >  Our current sound routines perform software sound sample mixing for use in g
> >ames. All the  mixing and transfers happen in a non-blocking function called u
> >pdate_jsound() which we call every 1/60th of a second in our main game loop. W
> >e find the total size of the hardware ring buffer and use MMAP writes to it. W
> >e effectively break the ring buffer into 1024 byte "fragments", and always kee
> >p one whole fragment ahead to ensure no underruns. We do this by the follwing:
> 
> best method:
> -----------
> 1) set the avail_min s/w parameter to the period size
> 2) call poll on the file descriptor(s) returned from
>    snd_pcm_poll_descriptors(). when you return from poll,
>    you know you have at least one period of data ready (possibly
>    more, so you need to check).
> 3) use snd_pcm_mmap_*() to handle mmap access. ALSA
>    doesn't provide simple access to mmap'ped buffers 
>    because this could not work for some classes of
>    ALSA devices.
> 
> survey the source of JACK (jackit.sf.net) for some ideas.
> 
> however, that probably won't work so well for you it doesn't integrate
> into your "game loop". for that, use snd_pcm_delay() to find out the
> gap between the application (s/w) pointer and the hardware pointer,
> then use the snd_pcm_mmap_*() calls from there.
> 
> its a lot more complex under ALSA. but thats because ALSA provides a
> lot of things that OSS does not, and doing everything via the simple
> system call interface that OSS uses makes it impossible to provide
> them "appropriately".
> 
> if you were writing software for musicians and studios rather than
> games and consumer media apps, check out JACK for a different, simpler
> and more powerful API (that uses ALSA internally).
> 
> --p
> 


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[Lorn Potter]

On Monday 12 January 2004 4:13 am, James Wright wrote:
>  I am currently looking into rewriting our current OSS sound routines to
> native ALSA, as it seems OSS will invariably be phased out now that the
> ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a
> great number of benefits for us.

Personally, I hope OSS compat will never be phased out. Why? OSS is simple, 
and concise. If I am writing a simple audio recording/playing app, I can get 
the job done using OSS code in _much_ less lines of code.


_Dont get me wrong_, ALSA is great and a lot more powerful than OSS, but it is 
lacking a simple API. 
Ever try to write an In/Out volume control mixer in OSS? Ever try to port that 
same mixer to ALSA?  From what I can gather (alsa seems to be lacking mixer 
docs/tutorial) , the only way to change the mic input level (alsa), I have to 
enumerate over every mixer gizmo and check to see if its the mic, and then 
change it if I think it appears to be the Mic.

Using OSS, I can do that in one line.






-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[Måns Rullgård]

Lorn Potter <lpotter@trolltech.com> writes:

> On Monday 12 January 2004 4:13 am, James Wright wrote:
>>  I am currently looking into rewriting our current OSS sound routines to
>> native ALSA, as it seems OSS will invariably be phased out now that the
>> ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a
>> great number of benefits for us.
>
> Personally, I hope OSS compat will never be phased out. Why? OSS is simple, 
> and concise. If I am writing a simple audio recording/playing app, I can get 
> the job done using OSS code in _much_ less lines of code.

I have to disagree.  For my music/video player, I've written both ALSA
and OSS output modules.  The ALSA module is 261 lines, the OSS module
258 lines, including comments and whitespace.  The ALSA module does
things that are more or less impossible with OSS, such as sample
accurate timing.

-- 
Måns Rullgård
mru@kth.se



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[James Wright]

On Mon, 12 Jan 2004 08:29:54 +1000
Lorn Potter <lpotter@trolltech.com> wrote:

> On Monday 12 January 2004 4:13 am, James Wright wrote:
> >  I am currently looking into rewriting our current OSS sound routines to
> > native ALSA, as it seems OSS will invariably be phased out now that the
> > ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a
> > great number of benefits for us.
> 
> Personally, I hope OSS compat will never be phased out. Why? OSS is simple, 
> and concise. If I am writing a simple audio recording/playing app, I can get 
> the job done using OSS code in _much_ less lines of code.
> 

  This is true, but for our application (games) we need very low latency, and hence fast
mixing and writes. It now seems pointless using our OSS code if its then going to be 
emulated by ALSA. I'm sure if i stick with ALSA i can get real nice results, its
just a steep learning curve for ALSA n00bs like me...  :(  If I was writing a basic 
audio app with little consideration for latency and efficiency i'd probably have stuck
with OSS and ALSA emulation...

  The main feature i'm interested in is the asychronous pcm playback, it means we can setup 
the sounds mixer, and not have to worry about calling an update_sound() function every 
1/20th of a sec...

> 
> _Dont get me wrong_, ALSA is great and a lot more powerful than OSS, but it is 
> lacking a simple API. 
> Ever try to write an In/Out volume control mixer in OSS? Ever try to port that 
> same mixer to ALSA?  From what I can gather (alsa seems to be lacking mixer 
> docs/tutorial) , the only way to change the mic input level (alsa), I have to 
> enumerate over every mixer gizmo and check to see if its the mic, and then 
> change it if I think it appears to be the Mic.
> 
> Using OSS, I can do that in one line.
> 

   I haven't looked at porting our /dev/mixer routines yet, sounds like its going to be fun!


> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[Kai Vehmanen]

On Mon, 12 Jan 2004, Lorn Potter wrote:

>>  I am currently looking into rewriting our current OSS sound routines to
>> native ALSA, as it seems OSS will invariably be phased out now that the
>> ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a
> Personally, I hope OSS compat will never be phased out. Why? OSS is simple, 
> and concise. If I am writing a simple audio recording/playing app, I can get 
> the job done using OSS code in _much_ less lines of code.

Excuse me!? A major problem of OSS/kernel is that it is _not_ concise.  
Different OSS drivers implement the OSS API slightly differently
(full-duplex, triggering, mmap support). This is a huge pain for the app
developers as you have to verify your app against n+1 different drivers.

With ALSA, when you write an application that works with one card, it is 
very likely that it will work perfectly on all the others too. This is 
made possible by the common alsa-kernel middle layer that is shared by all 
drivers. With OSS, there are n+1 implementations in the kernel of this 
middle level functionality. 

Now the commercial OSS (www.opensound.com) is a different thing. It too 
(like ALSA) provides coherent behaviour across different drivers.

> _Dont get me wrong_, ALSA is great and a lot more powerful than OSS, but it is 
> lacking a simple API. 
> Ever try to write an In/Out volume control mixer in OSS? Ever try to port that 
> same mixer to ALSA? 

Believe me, I agree with you 100% with regards to importance of
simplicity. ALSA still has some complex edges, but is has come a long way.
More documentation, tutorials and example code are still needed, but it
takes time (and volunteers) to create them. I'm sure help is appreciated.

> From what I can gather (alsa seems to be lacking mixer 
> docs/tutorial) , the only way to change the mic input level (alsa), I have to 
> enumerate over every mixer gizmo and check to see if its the mic, and then 
> change it if I think it appears to be the Mic.
[...]
> Using OSS, I can do that in one line.

But that's just one example. ALSA needs to support much more complex mixer
configurations than OSS, and this of course comes with a price. 

It is very difficult to try to hide all this complexity from the developer
without in the end limiting what the developer can do. So it's a question
of finding out a good balance between what can be done and how easy it is.
I guess currently ALSA is still too much on the complex side, but slowly
the correct balance will be found... So your input is very much 
appreciated, but at the same time, please don't lose hope just yet. :)

--
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[Lorn Potter]

On Monday 12 January 2004 9:11 am, Kai Vehmanen wrote:

> Now the commercial OSS (www.opensound.com) is a different thing. It too
> (like ALSA) provides coherent behaviour across different drivers.

I guess this is what I am talking about, really.


> > _Dont get me wrong_, ALSA is great and a lot more powerful than OSS, but
> > it is lacking a simple API.
> > Ever try to write an In/Out volume control mixer in OSS? Ever try to port
> > that same mixer to ALSA?
>
> Believe me, I agree with you 100% with regards to importance of
> simplicity. ALSA still has some complex edges, but is has come a long way.
> More documentation, tutorials and example code are still needed, but it
> takes time (and volunteers) to create them. I'm sure help is appreciated.

The problem here is, the people writing docs/tutorials need in depth knowledge 
of how this all works. And unfortunately, the best people to do this are the 
developers themselves. 


> But that's just one example. ALSA needs to support much more complex mixer
> configurations than OSS, and this of course comes with a price.
>
> It is very difficult to try to hide all this complexity from the developer
> without in the end limiting what the developer can do. So it's a question
> of finding out a good balance between what can be done and how easy it is.
> I guess currently ALSA is still too much on the complex side, but slowly
> the correct balance will be found... So your input is very much
> appreciated, but at the same time, please don't lose hope just yet. :)

Oh, I havent lost hope at all. I am very excited about ALSA nearing version 1.

I don't want to limit what alsa can do, only have access to a simple-ized part 
of the API, that's fast and easy for developers to write.  Which is what I 
view the OSS compat. to be.

I work with embedded devices, and so I am always thinking of ways to optimize 
the code and make apps smaller, which also means writing more app with less 
code.



> --
>  http://www.eca.cx
>  Audio software for Linux!

-- 
Lorn 'ljp' Potter
Qtopia Community Manager
lpotter at trolltech.com



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[Jaroslav Kysela]

On Mon, 12 Jan 2004, Lorn Potter wrote:

> > Believe me, I agree with you 100% with regards to importance of
> > simplicity. ALSA still has some complex edges, but is has come a long way.
> > More documentation, tutorials and example code are still needed, but it
> > takes time (and volunteers) to create them. I'm sure help is appreciated.
> 
> The problem here is, the people writing docs/tutorials need in depth knowledge 
> of how this all works. And unfortunately, the best people to do this are the 
> developers themselves. 

Basically, developers are not good documentation writers, because they 
might ommit important things for people which need some introduction. I 
still hope, that the community will ask us for deep details and send us 
pieces of documentation back.

> > But that's just one example. ALSA needs to support much more complex mixer
> > configurations than OSS, and this of course comes with a price.
> >
> > It is very difficult to try to hide all this complexity from the developer
> > without in the end limiting what the developer can do. So it's a question
> > of finding out a good balance between what can be done and how easy it is.
> > I guess currently ALSA is still too much on the complex side, but slowly
> > the correct balance will be found... So your input is very much
> > appreciated, but at the same time, please don't lose hope just yet. :)
> 
> Oh, I havent lost hope at all. I am very excited about ALSA nearing version 1.
> 
> I don't want to limit what alsa can do, only have access to a simple-ized part 
> of the API, that's fast and easy for developers to write.  Which is what I 
> view the OSS compat. to be.
> 
> I work with embedded devices, and so I am always thinking of ways to optimize 
> the code and make apps smaller, which also means writing more app with less 
> code.

Yes, we're aware that our APIs are rather too much complicated for simple 
applications. We are designing the very simple (current name ordinary) 
APIs to let more developers join us. But as Kai noticed, these APIs will 
be a bit limited, so they won't be intended for more complex applications.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[Paul Davis]

>Yes, we're aware that our APIs are rather too much complicated for simple 
>applications. We are designing the very simple (current name ordinary) 
>APIs to let more developers join us. But as Kai noticed, these APIs will 
>be a bit limited, so they won't be intended for more complex applications.

Jaroslav, please don't spend much time on this. There are no
indications that ALSA is going to be picked as a native API by
freedesktop.org, nor any of the incarnations of various X
organizations as a network-transparent API. Simple applications are
just not going to use ALSA, they will be using some API approved by
GNOME/KDE/freedesktop, which will sit happily on top of the more
complex API that alsa-lib currently provides.

There are much more important things that ALSA needs to fix, like the
asoundrc syntax/handling/setup.

--p


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: Moving from OSS to ALSA

[Takashi Iwai]

At Mon, 12 Jan 2004 07:54:37 -0500,
Paul Davis wrote:
> 
> >Yes, we're aware that our APIs are rather too much complicated for simple 
> >applications. We are designing the very simple (current name ordinary) 
> >APIs to let more developers join us. But as Kai noticed, these APIs will 
> >be a bit limited, so they won't be intended for more complex applications.
> 
> Jaroslav, please don't spend much time on this. There are no
> indications that ALSA is going to be picked as a native API by
> freedesktop.org, nor any of the incarnations of various X
> organizations as a network-transparent API. Simple applications are
> just not going to use ALSA, they will be using some API approved by
> GNOME/KDE/freedesktop, which will sit happily on top of the more
> complex API that alsa-lib currently provides.
> 
> There are much more important things that ALSA needs to fix, like the
> asoundrc syntax/handling/setup.

i agree also about the PCM.  there are many other PCM abstractions
like PortAudio.  of course, it'd be nice to have one in ALSA itself,
though.

but remember that the mixer is a different story.
there is no other abstraction.  the current mixer representation is
too copmlex and the abstraction itself is not complete.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html