-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This isn't really a serious question, but I just encountered some stuff
about userspace sound drivers for Linux and was like O_o so now I'm
curious as to the design aspect here. I can't think of a good way to do
it (where 'good' means something more than 'ugly hack').
So here's my input on this, and if anyone cares to enlighten me maybe
you can bounce some responses back. It'll be a good learning experience
for me.
- General transport and context switches
In general, transporting sound data in and out of kernel space is a
horrid thought. Consider the latencies, which all real-time audio
people will quickly get angry about. Write sound; context switch; sound
in driver; context switch back. This over and over? Now we all know
better than that.
So my first impulse would be using the generic kernel-user transport
facilities like NETLNK. But at a glance this doesn't seem to do
anything for me; this would still be writing to a socket, which causes a
syscall into kernel space. In short, you're stuck with context switches.
On the up-side, in any scheme the user space program has to shift data
into the kernel; with alsa it's written to a /proc interface, which
causes a context switch into kernel space AFAIK because it calls write()
to an fd. Still, we're wasting time copying to another process' memory
space.
- Ring-1, Ring-2
I have heard that these mysterious privilege levels allow bitmaps to
give direct hardware access, i.e. to PCI devices. Through this mystical
magic, a driver could directly access a sound card. This opens up new
possibilities. . or does it?
First off how the heck complex is userspace PCI control, and what gains
do you really get? Won't every syscall() become a sudden context
switch? Or (as I suspect and would like to find out) does the "overhead
of context switching" mainly imply the copy_from_user() function and the
process of rewriting a lot of PTEs into a new privilege level (kernel
instead of user)?
Assuming that you can implement direct hardware access or at least
direct access to memory to avoid the context switch (in the manner I'm
assuming the latency comes from), this may become actually faster.
Still you're copying memory from Ring-3 (user) to Ring-1 or Ring-2, so
there are no gains here.
- Shared mapping?
If my assumption on how this works is correct, then copy_from_user() is
difficult because you have to walk the range of passed VM addresses and
change/copy affected PTEs. The old PTEs become non-writable
(copy-on-write trigger) and the new PTEs are created (non-writable CoW
and of course Ring-3 privilege) for the kernel.
This assumption brings an interesting thought: what about a shared
mapping? An area of memory writable by userspace and readable by the
kernel? This seems silly. Under the assumptions I've made, this would
still require CoWing existing PTEs or flat out copying things over.
Obviously I lack understanding of the problem; none of this solves
anything, and this is typical overhead whenever you allocate memory,
even from userspace.
So we come to an interesting thought: I've found yet another
interesting bit of kernel design that I don't understand, and am curious
of. I understand basic memory management concepts and preemptive
multitasking just because of pestering the LKML from time to time; might
as well go for a little more and see if you guys bite again. Any takers?
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRA5XQws1xW0HCTEFAQLr7g//Yqnj5hIbANQR/SsiirkLhYAcM7DC3lGe
vi50fu7YZSwaDNJ/NKWjHVmiuI1UWLehEe6n8BWHYR9tq0JzNzwwpEPUWUxIv7tp
TsKKWR4uP8YYbFoFoNo8zK/kJQiV0ynVvuBCVCYm3OUqBi8hIqKut0GgyZc4qo7M
aOmq3mFlw5zITfYV2pYVq9ttTU2ZJ36pXU4gJJi0+V5KVO51ZuAXDxDB6oaLewq7
csayDae/yy9Aene44fSSuO+bfS6JPNq9uTXS42v0bcYkZm+DppSTaZcPetj1cMcU
qM1d/0jh6bQwVpDRb7A7xumP+TfQM7J8/5rR2TFTpgc63qA1Fyzu5qd/hJ9xz28A
pum/36ZbF/fiLR5qwMB3tlwN9z6f1MrEmEzOKtCap/Mq3IklSnyc429mpTs8smjZ
WzbRaLU2rNxgL2KFDOZvhrfN0PP4nu+DDSauTmYdaSHfdNQ0tlvZAapq8SMQy5LU
VAY3ZDEMP4qAIGMfXTRR49JAuM0OLWpV/fXeE9Uwv0KIyomfw/TJvW20O2vblN06
Ryj4HGwELeaZpc+D8E6eWXSllX/16qp5zgXAFnNgvBAXfRnaKPzSnhNOdEozNhxM
oFk3Kf9PoyEn3fqRFXJi+f9o02VvDAEY/6EOwsALUOAWADqbW+D/ku7MKEMt7pFT
Jo/dyODrxfA=
=YKVj
-----END PGP SIGNATURE-----
On Tue, 7 Mar 2006, John Richard Moser wrote:
> In general, transporting sound data in and out of kernel space is a
> horrid thought. Consider the latencies, which all real-time audio
> people will quickly get angry about. Write sound; context switch; sound
> in driver; context switch back. This over and over? Now we all know
> better than that.
Nope. If you have a cache coherent architecture like x86, ALSA mmaps
directly the DMA buffer to application and even pointers to this buffer
are mmaped, thus there is no content switch when apps are doing r/w and
there is "zero data copy". The only contents switch is when apps call
poll(), but you should do it, otherwise you'll eat all cpu time.
> into the kernel; with alsa it's written to a /proc interface, which
Using /proc? Where? I've not noticed it :-)
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaroslav Kysela wrote:
> On Tue, 7 Mar 2006, John Richard Moser wrote:
>
>> In general, transporting sound data in and out of kernel space is a
>> horrid thought. Consider the latencies, which all real-time audio
>> people will quickly get angry about. Write sound; context switch; sound
>> in driver; context switch back. This over and over? Now we all know
>> better than that.
>
> Nope. If you have a cache coherent architecture like x86, ALSA mmaps
> directly the DMA buffer to application and even pointers to this buffer
> are mmaped, thus there is no content switch when apps are doing r/w and
> there is "zero data copy". The only contents switch is when apps call
> poll(), but you should do it, otherwise you'll eat all cpu time.
>
Awesome. Nice design :) I hath learned today and I woke up 10 minutes
ago.
>> into the kernel; with alsa it's written to a /proc interface, which
>
> Using /proc? Where? I've not noticed it :-)
I thought that was what /proc/asound/card0/ was for? :)
>
> Jaroslav
>
> -----
> Jaroslav Kysela <[email protected]>
> Linux Kernel Sound Maintainer
> ALSA Project, SUSE Labs
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRA8DlQs1xW0HCTEFAQKeqg//SunhyEf8o4MGpQkrrWImJJ5HOaYFragk
pgr++6lXTxNTJflpKRO+1iblYCrkakOdLaUn01UZqgaxzquaFEuw9N7bNUpI8Fjn
MzS11rYsttZMpfUyT5PiAbMhkiguvBzVv24wcsWwsg83RsH73OZtGGu9BC8SNrw/
jxaJv+B893R6LVIvhMMbRSYAizAEBqfiatttr64G2wNdQ8Hn58fJjStNTyYHFSWo
EwsZe19xOW3XgTlRb3S12e6pw9kxDM46/hxpceXB0PwqUtq8kbD8I9Jeb838M3qf
XM6+HgXYtSpbJ7zMYVPFI//vo140oHSvK8so0Ifz5NQ561AnqIteDPPKqwJTr02D
BqcDZkrXNYoY3qP3rDnTobMciVJycSF6OJp+GHrDxoieV/kKnzjLbvcA4xYU8LmV
PZv0/zNX2ZulrKpnVE8MitwurXnhEVZ8NG82ie7V3COu3JyNzAx+uvQCjUIRDef3
ne2icJcyY6kOuWFL0+FslCW1DwyNt9169PEzvJf5Ns590vEwmaxH9u5GfMsjmPHC
jmh6zmxNyqSJ05XpWGAeM3iPVgeD0aTqi5dnbXIB7AUF/hmhoCf3co7rQ+y7404g
YR7z0vaoK551wCJbkSLa4lnl7oo6lpt8LdS12wIx0c5RGwICTHzCG9uCfAZk+RqX
TedLwHW7cfQ=
=BSFO
-----END PGP SIGNATURE-----
At Wed, 08 Mar 2006 11:17:26 -0500,
John Richard Moser wrote:
>
> >> into the kernel; with alsa it's written to a /proc interface, which
> >
> > Using /proc? Where? I've not noticed it :-)
>
> I thought that was what /proc/asound/card0/ was for? :)
/proc is not referred from alsa-lib, i.e. programs don't access them.
It's just for users who want to read some information.
Takashi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Takashi Iwai wrote:
> At Wed, 08 Mar 2006 11:17:26 -0500,
> John Richard Moser wrote:
>>>> into the kernel; with alsa it's written to a /proc interface, which
>>> Using /proc? Where? I've not noticed it :-)
>> I thought that was what /proc/asound/card0/ was for? :)
>
> /proc is not referred from alsa-lib, i.e. programs don't access them.
> It's just for users who want to read some information.
>
This makes me wonder then how stuff is set up. There's no device, is
there a sound card syscall now?
>
> Takashi
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRA8oxQs1xW0HCTEFAQKGuA//RX/shtqKKPYQwSdP8O+Ai5C7VnQV+GiN
I/+OalJIjfK/zUiJP6CIsFcNxTFTPiUJOwF/MKguiwWHsMwr/CWu/MVqAQEDC/yP
UO1hSLcGKTp8xHh5jSIyotjisXaGx8rSq0Ye8ZDGPgDlVXb27USkmqWwySBCO+OJ
pFtzGy9GxuJ+1OWoiXd0ytTSVm6WPEX/zFNsQmY4AnFid5aTrlxjDjQpx2cxt4iq
j1nc+kkt450m4y233Cuncb7UXI/WzVhUX89dJf4RkjMKs5QDBvtQhzTB4K3PPByg
l13xQq8si/knA8jcYcEbtHrzh+bTlvSwa8hJfONG3tbShHedJNQA+kLm6zpwm/kw
hGkW0/IYU/Kpxh6Hg8yqb67ibbLFKjNc0njwRTZ5CLkE4pUwT/NASY4j5IcXYMrp
bOla+ASuy/g0dYngmh0wK4tqJJSfl+SdZt+AkeVm6x5XtYv2k2uEhfQsDWpqhp0z
TXiauuLhdJZ3mle21ZcY634Ws9C2vLmH6/TBQAgb0azryo9W4FQvEfPszbPyln04
irNC/VkKQ9vDr3spjXlqW9hCCD176+uOoHsI79WnUiz1EUdQ02kZ4mLm/i4JuXS8
Y8rezaHx7iypylVlI7c5CaDuEnrsBfvX7i/FqUa3/E0yH0v2wU0EcmC2K1OF1d7M
q0jA3aTHj+o=
=wEi9
-----END PGP SIGNATURE-----
At Wed, 08 Mar 2006 13:56:06 -0500,
John Richard Moser wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Takashi Iwai wrote:
> > At Wed, 08 Mar 2006 11:17:26 -0500,
> > John Richard Moser wrote:
> >>>> into the kernel; with alsa it's written to a /proc interface, which
> >>> Using /proc? Where? I've not noticed it :-)
> >> I thought that was what /proc/asound/card0/ was for? :)
> >
> > /proc is not referred from alsa-lib, i.e. programs don't access them.
> > It's just for users who want to read some information.
> >
>
> This makes me wonder then how stuff is set up. There's no device, is
> there a sound card syscall now?
You must have /dev/snd/* files, and the access is via normal
syscalls... Check strace of your program.
Takashi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Takashi Iwai wrote:
> At Wed, 08 Mar 2006 13:56:06 -0500,
> John Richard Moser wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Takashi Iwai wrote:
>>> At Wed, 08 Mar 2006 11:17:26 -0500,
>>> John Richard Moser wrote:
>>>>>> into the kernel; with alsa it's written to a /proc interface, which
>>>>> Using /proc? Where? I've not noticed it :-)
>>>> I thought that was what /proc/asound/card0/ was for? :)
>>> /proc is not referred from alsa-lib, i.e. programs don't access them.
>>> It's just for users who want to read some information.
>>>
>> This makes me wonder then how stuff is set up. There's no device, is
>> there a sound card syscall now?
>
> You must have /dev/snd/* files, and the access is via normal
> syscalls... Check strace of your program.
>
Ahh nice, I was always looking for /dev/dsp :>
>
> Takashi
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRA86Pws1xW0HCTEFAQIr9w//at9VpczxSKrCUzQGMYe33SW2vrksVVIg
dTE12O1cc3gw0PK5UaD/QiN9+uoHKXY1YSkBBeCQQ2We50txjuy30jZ0j8PhkE22
PmuMb2knq9isspAT6Mr0ErRLS1+2FEvVN52yWwustl8cMiGrq812bYq63YHhGTPe
1b587S9+/wrEmswfA5/dvfJ+iEr3rHM0X7JPzJ721ayU1oeisAHw2GQCiXxQfwXZ
aqOCnDRr7VgiPgnMC0nu8JVbNEdvJru4Dwgkc2siXoLnYmFYOiLv8JzujDJH3NfP
aVxJ/NaoryvDSWXTcLOhm2nXKO7hD6id6wmd4ncSLedieK2Pw9WyAnVl40JguYgG
OrTzmwJsYcc++isyLcYoDyJi861Urhly4Umnx8GQRxhpzJJ31eX+6pnNaic1f9Rv
CNKOKrhLYG1AjqvDn0A1gyarMbXuXWu9D8Cjtv89nISr3AbGhq2Hz4oG78zRTiOX
S56wnL8432RwhahQOkMSyJVdrxszN56FYiraWwfclrpAdE8TujV1YPYPG8qo2EGH
9vk6O0ZVccZUiyt3WLnyl+r/PLdsEaiFzrG7l0HANWq6KcCES8FClhfrWueCFQlM
4e7yAofQSKzJ1GrofaghVLloEJjoAoCWrJcVHMv6gAkPa8m8pwK9tUul3FRdDMD/
1EHU/9tOMmY=
=8+gV
-----END PGP SIGNATURE-----