linux-kernel - Re: alsa was Re: ABI coupling to hypervisors via CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070315090330.GF16330@elf.ucw.cz>
Date:	Thu, 15 Mar 2007 10:03:30 +0100
From:	Pavel Machek <pavel@....cz>
To:	Jaroslav Kysela <perex@...e.cz>
Cc:	Lee Revell <rlrevell@...-job.com>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Zachary Amsden <zach@...are.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>, akpm@...ux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Chris Wright <chrisw@...s-sol.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: alsa was Re: ABI coupling to hypervisors via CONFIG_PARAVIRT

Hi!

> > > >I think the sound example to the right really shows it. 
> > > >/dev/dsp has a
> > > >consistent ABI on a ton of systems. The API below it, 
> > > >varies. Linux got
> > > >file_operations and ALSA. Solaris/BSD may have its
> > > >vnode-and-so-on-functions and some sort of OSS.
> > > 
> > > I think this is a poor example as applications lose a 
> > > lot of
> > > functionality (multiple stream mixing, software volume 
> > > control, etc)
> > > by going through the legacy /dev/dsp interface vs. using 
> > > native ALSA.
> > 
> > OTOH /dev/dsp is nice, clean, unixy interface, while alsa creates ugly
> > ABI you should not even use unless you are libalsa. ouch.
> 
> Pavel, calm down. 

I'm pretty calm, thank you.

> World is not perfect and there are always probes to 
> optimize things. We use standard file operations - open/close/ioctl/mmap, 
> too.

Unfortunately AlSA _does not_ provide hardware abstraction. Instead,
it relies on libalsa in userland to do the kernel work. That means
that testing sound is ugly.

Plus, it made some "interesting choices" with naming, basically
inventing parallel system to /dev/. (Why do I have to specify "card 0"
number in xmms, and WTF it means? Why can't alsa use device paths as
rest of sane world?)

So... in dsp, if I wanted to record sound, I did

	cat /dev/dsp > /tmp/foo; cat /tmp/foo > /dev/dsp

If that worked, I had usable sound system, and if it broke, I knew it
is kernel fault. 

With alsa it is

	download & install alsalib
	download & install alsautils
	create 1007 nodes in /dev
	launch alsamixer, figure out what to do from inadequate descriptions
	launch arecord, try to guess some suitable options
	launch aplay, try to guess some options

...if it does not work, it may be a kernel problem or userspace
problem; I'm left with debugging both. That makes alsa pretty much
untestable.

(For _my_ usage, something like "alsatest" that is self-contained,
preferably statically linked, and just tests microphone and sound
output would be nice. But that does not fix the fact that alsa is
broken by design).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/