TODO list

TODO list

[James Courtier-Dutton]

Hi,

I was wondering what the current TODO list is for ALSA. The current one 
in alsa-driver hg seems somewhat out of date.
My list has the following, in no particular order:
1) Finish reverse engineering some sound cards (e.g. Creative EMU1212M)
2) Implement needed features on some already reverse engineered cards. 
e.g. The Creative Audigy PCMCIA.
3) Add dB gain architecture.
4) Improve dmix, specifically for 44.1 kHz and games like Doom3. Perhaps 
using the system clock, adjusted to match the sound card hardware clock, 
to provide accurate sample timing, at multiple different sample rates, 
irrespective of the rate the sound card runs at.
5) Perhaps use the system clock to help resample so that user space sees 
a single sample rate clock, but let alsa-lib automatically adjust for 
the different clocks of different sound cards.
6) Think of some way to simplify the mixer interface for user space 
mixers. Surely, it does not have to be so complex as it currently is?
7) Provide better OSS emulation support. E.g. redirect all access to 
/dev/dsp into user space so it can use all the features of alsa-lib 
without needing aoss. (aoss does not work if the application uses 
dynamically linked audio driver plugins.






-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: TODO list

[Lee Revell]

On Thu, 2006-05-25 at 19:10 +0100, James Courtier-Dutton wrote:
> 7) Provide better OSS emulation support. E.g. redirect all access to 
> /dev/dsp into user space so it can use all the features of alsa-lib 
> without needing aoss. (aoss does not work if the application uses 
> dynamically linked audio driver plugins.
> 

What mechanisms does the kernel provide that could help with this?

Lee



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: TODO list

[Takashi Iwai]

At Thu, 25 May 2006 19:10:30 +0100,
James Courtier-Dutton wrote:
> 
> Hi,
> 
> I was wondering what the current TODO list is for ALSA. The current one 
> in alsa-driver hg seems somewhat out of date.

Yep.  Some documents in alsa-driver tree are obsoleted.  Perhaps
better to remove them.

> My list has the following, in no particular order:
> 1) Finish reverse engineering some sound cards (e.g. Creative EMU1212M)
> 2) Implement needed features on some already reverse engineered cards. 
> e.g. The Creative Audigy PCMCIA.
> 3) Add dB gain architecture.
> 4) Improve dmix, specifically for 44.1 kHz and games like Doom3.

Actually, it's not dmix but rate plugin that causes more problems...

> Perhaps 
> using the system clock, adjusted to match the sound card hardware clock, 
> to provide accurate sample timing, at multiple different sample rates, 
> irrespective of the rate the sound card runs at.
> 5) Perhaps use the system clock to help resample so that user space sees 
> a single sample rate clock, but let alsa-lib automatically adjust for 
> the different clocks of different sound cards.
> 6) Think of some way to simplify the mixer interface for user space 
> mixers. Surely, it does not have to be so complex as it currently is?
> 7) Provide better OSS emulation support. E.g. redirect all access to 
> /dev/dsp into user space so it can use all the features of alsa-lib 
> without needing aoss. (aoss does not work if the application uses 
> dynamically linked audio driver plugins.

A dummy kernel driver just to translate syscalls to communication with
a user daemon is the only possible workaround, IMO.  This idea was
denied once quite ago, but I don't see any other good way right now.


My additional wishes are:

8) Improve release engineering.

9) Better organized Web pages and BTS.

10) Build standard test suite and diagnosis tools.


Takashi

Re: TODO list

[James Courtier-Dutton]

Takashi Iwai wrote:
>> 7) Provide better OSS emulation support. E.g. redirect all access to 
>> /dev/dsp into user space so it can use all the features of alsa-lib 
>> without needing aoss. (aoss does not work if the application uses 
>> dynamically linked audio driver plugins.
>>     
>
> A dummy kernel driver just to translate syscalls to communication with
> a user daemon is the only possible workaround, IMO.  This idea was
> denied once quite ago, but I don't see any other good way right now.
>   
That is my thought as well. When I looked into the idea some time ago, I 
concluded that is would be a rather large project, so I did not proceed 
as I have other more important (for me) ALSA features.
Can a user space daemon create /dev files, so that the application calls 
never actually reach kernel space?
If we can create such a pipe, that can forward 
open/close/read/write/ioctl, that should be enough. We then have to 
think about shared memory to look like DMA space to the application 
using us.

>
> My additional wishes are:
>
> 8) Improve release engineering.
>
> 9) Better organized Web pages and BTS.
>
> 10) Build standard test suite and diagnosis tools.
>
>   
The words "Under staffed" comes to mind. :-)
> Takashi
>   

James

Re: TODO list

[Takashi Iwai]

At Fri, 26 May 2006 12:29:11 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> >> 7) Provide better OSS emulation support. E.g. redirect all access to 
> >> /dev/dsp into user space so it can use all the features of alsa-lib 
> >> without needing aoss. (aoss does not work if the application uses 
> >> dynamically linked audio driver plugins.
> >>     
> >
> > A dummy kernel driver just to translate syscalls to communication with
> > a user daemon is the only possible workaround, IMO.  This idea was
> > denied once quite ago, but I don't see any other good way right now.
> >   
> That is my thought as well. When I looked into the idea some time ago, I 
> concluded that is would be a rather large project, so I did not proceed 
> as I have other more important (for me) ALSA features.
> Can a user space daemon create /dev files, so that the application calls 
> never actually reach kernel space?

No, only the kernel driver can handle certain syscalls like ioctl and
mmap properly.  So, it must be a kernel driver that communicated with
OSS apps (unless using LD_PRELOAD hack).

The driver interprets each syscall to a certain protocol communicated
with a dedicated daemon, and the daemon interprets it again to the
real ALSA access.

> If we can create such a pipe, that can forward 
> open/close/read/write/ioctl, that should be enough. We then have to 
> think about shared memory to look like DMA space to the application 
> using us.

mmap would be still tricky, maybe a kind of emulation via read/write.


Takashi

Re: TODO list

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Fri, 26 May 2006 12:29:11 +0100,
> James Courtier-Dutton wrote:
>   
>> Takashi Iwai wrote:
>>     
>>>> 7) Provide better OSS emulation support. E.g. redirect all access to 
>>>> /dev/dsp into user space so it can use all the features of alsa-lib 
>>>> without needing aoss. (aoss does not work if the application uses 
>>>> dynamically linked audio driver plugins.
>>>>     
>>>>         
>>> A dummy kernel driver just to translate syscalls to communication with
>>> a user daemon is the only possible workaround, IMO.  This idea was
>>> denied once quite ago, but I don't see any other good way right now.
>>>   
>>>       
>> That is my thought as well. When I looked into the idea some time ago, I 
>> concluded that is would be a rather large project, so I did not proceed 
>> as I have other more important (for me) ALSA features.
>> Can a user space daemon create /dev files, so that the application calls 
>> never actually reach kernel space?
>>     
>
> No, only the kernel driver can handle certain syscalls like ioctl and
> mmap properly.  So, it must be a kernel driver that communicated with
> OSS apps (unless using LD_PRELOAD hack).
>
> The driver interprets each syscall to a certain protocol communicated
> with a dedicated daemon, and the daemon interprets it again to the
> real ALSA access.
>
>   
>> If we can create such a pipe, that can forward 
>> open/close/read/write/ioctl, that should be enough. We then have to 
>> think about shared memory to look like DMA space to the application 
>> using us.
>>     
>
> mmap would be still tricky, maybe a kind of emulation via read/write.
>
>
> Takashi
>   

For mmap, all that happens is that the application asks for a mmap 
address from the kernel.
If we could get the kernel to manipulate shared memory, so that the mmap 
address given to the application is shared with the daemon, surely that 
would work.
Unfortunately, this might require some kernel memory manager modifications.
Shall I ask about this on the kernel mm list?

James

Re: TODO list

[Takashi Iwai]

At Fri, 26 May 2006 17:33:39 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 26 May 2006 12:29:11 +0100,
> > James Courtier-Dutton wrote:
> >   
> >> Takashi Iwai wrote:
> >>     
> >>>> 7) Provide better OSS emulation support. E.g. redirect all access to 
> >>>> /dev/dsp into user space so it can use all the features of alsa-lib 
> >>>> without needing aoss. (aoss does not work if the application uses 
> >>>> dynamically linked audio driver plugins.
> >>>>     
> >>>>         
> >>> A dummy kernel driver just to translate syscalls to communication with
> >>> a user daemon is the only possible workaround, IMO.  This idea was
> >>> denied once quite ago, but I don't see any other good way right now.
> >>>   
> >>>       
> >> That is my thought as well. When I looked into the idea some time ago, I 
> >> concluded that is would be a rather large project, so I did not proceed 
> >> as I have other more important (for me) ALSA features.
> >> Can a user space daemon create /dev files, so that the application calls 
> >> never actually reach kernel space?
> >>     
> >
> > No, only the kernel driver can handle certain syscalls like ioctl and
> > mmap properly.  So, it must be a kernel driver that communicated with
> > OSS apps (unless using LD_PRELOAD hack).
> >
> > The driver interprets each syscall to a certain protocol communicated
> > with a dedicated daemon, and the daemon interprets it again to the
> > real ALSA access.
> >
> >   
> >> If we can create such a pipe, that can forward 
> >> open/close/read/write/ioctl, that should be enough. We then have to 
> >> think about shared memory to look like DMA space to the application 
> >> using us.
> >>     
> >
> > mmap would be still tricky, maybe a kind of emulation via read/write.
> >
> >
> > Takashi
> >   
> 
> For mmap, all that happens is that the application asks for a mmap 
> address from the kernel.
> If we could get the kernel to manipulate shared memory, so that the mmap 
> address given to the application is shared with the daemon, surely that 
> would work.

The sharing of memory between the app and the daemon is easy via a
simple mmap invoked from both sides.  But, sharing the mmapped buffer
from a sound driver between the daemon and the app over yet another
driver is a tough problem, because the buffer is strictly bound to the
sound card hardware.

> Unfortunately, this might require some kernel memory manager modifications.
> Shall I ask about this on the kernel mm list?

I don't think it's worthy at this stage at all.
We need to consider first the basic design more deeply.
For example, even if we get the mmapped buffer, it's not enough for
the whole operation, especially when the period/buffer size doesn't
match with whta OSS requires.


Takashi

Re: TODO list

[James Courtier-Dutton]

Takashi Iwai wrote:
>> For mmap, all that happens is that the application asks for a mmap 
>> address from the kernel.
>> If we could get the kernel to manipulate shared memory, so that the mmap 
>> address given to the application is shared with the daemon, surely that 
>> would work.
>>     
>
> The sharing of memory between the app and the daemon is easy via a
> simple mmap invoked from both sides.  But, sharing the mmapped buffer
> from a sound driver between the daemon and the app over yet another
> driver is a tough problem, because the buffer is strictly bound to the
> sound card hardware.
>   

> We need to consider first the basic design more deeply.
> For example, even if we get the mmapped buffer, it's not enough for
> the whole operation, especially when the period/buffer size doesn't
> match with whta OSS requires.
>
>
> Takashi
>   

I was thinking more along the lines of User App -> OSS kernel shim -> 
userland daemon buffer, one buffer per user app -> alsa-lib.
So, the mmap would not be a real mmap, it would be a simple matter of 
tricking the User app into thinking it is mmapped. It would be a double 
buffer really.
So, the daemon buffer would just be whatever size the OSS user app 
wanted, and the daemon would then pass it's contents to alsa-lib or 
jackd as and when needed.
All this would probably only be possible if some high res timer source 
(e.g. the system timer) was used to trigger the period boundaries. I 
think I mentioned that idea some time ago. Maybe we should just aim for 
that TODO item to help dmix work better at 44100Hz, and then worry about 
the OSS kernel shim after that.
Maybe by that time....OSS would have disappeared! :-)

James

Re: TODO list

[Takashi Iwai]

At Fri, 26 May 2006 18:30:36 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> >> For mmap, all that happens is that the application asks for a mmap 
> >> address from the kernel.
> >> If we could get the kernel to manipulate shared memory, so that the mmap 
> >> address given to the application is shared with the daemon, surely that 
> >> would work.
> >>     
> >
> > The sharing of memory between the app and the daemon is easy via a
> > simple mmap invoked from both sides.  But, sharing the mmapped buffer
> > from a sound driver between the daemon and the app over yet another
> > driver is a tough problem, because the buffer is strictly bound to the
> > sound card hardware.
> >   
> 
> > We need to consider first the basic design more deeply.
> > For example, even if we get the mmapped buffer, it's not enough for
> > the whole operation, especially when the period/buffer size doesn't
> > match with whta OSS requires.
> >
> >
> > Takashi
> >   
> 
> I was thinking more along the lines of User App -> OSS kernel shim -> 
> userland daemon buffer, one buffer per user app -> alsa-lib.
> So, the mmap would not be a real mmap, it would be a simple matter of 
> tricking the User app into thinking it is mmapped. It would be a double 
> buffer really.

Then it's as same as what I thought.  This implementation is pretty
easy.  Let both side call mmap just like POSIX shm does.


Takashi

Re: TODO list

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 1660 bytes --]

Hah, finally found the thread. I knew there was something like this
lingering about.

> I was thinking more along the lines of User App -> OSS kernel shim -> 
> userland daemon buffer, one buffer per user app -> alsa-lib.
> So, the mmap would not be a real mmap, it would be a simple matter of 
> tricking the User app into thinking it is mmapped. It would be a double 
> buffer really.
> So, the daemon buffer would just be whatever size the OSS user app 
> wanted, and the daemon would then pass it's contents to alsa-lib or 
> jackd as and when needed.
> All this would probably only be possible if some high res timer source 
> (e.g. the system timer) was used to trigger the period boundaries. I 
> think I mentioned that idea some time ago. Maybe we should just aim for 
> that TODO item to help dmix work better at 44100Hz, and then worry about 
> the OSS kernel shim after that.

I wonder if the kernel 'shim' should really be tied to OSS. I see
another application for this: bluetooth audio. Currently, there's a
kernel plugin that as far as I can tell doesn't do much more than
exactly this, push data it received from one side to the other side, the
actual communication is done in userspace. If we had a generic 'sound
driver' below alsa that could create any card with any mixer (compare to
the uinput layer!) then we could do *all* of that in userspace with
standard means.

And for the OSS emulation it'd just mean re-using that existing
interface and the existing oss emulation code (which moves and is
changed to only apply over virtual devices), and putting all the tricky
stuff into the oss daemon.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

[-- Attachment #2: Type: text/plain, Size: 299 bytes --]

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel