I just fixed a number of major bugs in the undocumented linuxaudiodev module. I ended up spending about an hour reading the excellent Open Sound System (OSS) Programmer's Guide to figure out what the module was trying to do and why it wasn't working on my Linux box. After reading the module and the OSS guide, it is clear to me that we need a complete re-write. The module itself is just a wrapper around a bunch of read, write, and ioctl calls. It could all be implemented in pure Python. I propose we develop a Python module for Python 2.1 and call it osslib. There is nothing at all that is Linux-specific about the interface being used. The OSS guide mentions a plethora of platforms that it supports. In the interim, I have fixed some of the most egregious problems. I would appreciate it if Linux users could try out the fixes and the new test case. On my machine it still sounds awful, but at least the sound can be heard. Jeremy
On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote:
After reading the module and the OSS guide, it is clear to me that we need a complete re-write. The module itself is just a wrapper around a bunch of read, write, and ioctl calls. It could all be implemented in pure Python.
So, is there any point in releasing linuxaudiodev at all, then, if it needs a complete rewrite? --amk
I propose we develop a Python module for Python 2.1 and call it osslib. There is nothing at all that is Linux-specific about the interface being used. The OSS guide mentions a plethora of platforms that it supports.
Have you evaluated http://net.indra.com/~tim/ossmodule/ ?
"AMK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes:
AMK> On Fri, Oct 06, 2000 at 03:11:43PM -0400, Jeremy Hylton wrote:
After reading the module and the OSS guide, it is clear to me that we need a complete re-write. The module itself is just a wrapper around a bunch of read, write, and ioctl calls. It could all be implemented in pure Python.
AMK> So, is there any point in releasing linuxaudiodev at all, then, AMK> if it needs a complete rewrite? I would be include to chuck it, except that it also shipped with 1.6. I would hestitate to deprecate it so far into the release process. jeremy
"DA" == David Ascher <DavidA@ActiveState.com> writes:
DA> Have you evaluated http://net.indra.com/~tim/ossmodule/ Okay. I took a quick look. It's really old (July 1997). It looks like a more reasonable wrapping than linuxaudiodev, although I would want to review it more carefully against the OSS programmer's guide. I would prefer a pure Python solution, because the code would be shorter and easier to read and maintain. It may be, however, that the ossmodule is still up-to-date; if so, it may be easier to use it than to rewrite it. Jeremy
On Fri, 6 Oct 2000, Jeremy Hylton wrote:
After reading the module and the OSS guide, it is clear to me that we need a complete re-write. The module itself is just a wrapper around a bunch of read, write, and ioctl calls. It could all be implemented in pure Python.
True. I think your osslib is a good idea. I wanted to take on this sort of project myself a few weeks ago but never had the time to really get started. From playing with the test script, i think all we care about having in C is audioop (and that's just for ulaw conversion). I would like to fix audioop so we can expect it to be present as a standard module; then we can have a module written in Python that provides uniform sound support for all platforms.
On my machine it still sounds awful, but at least the sound can be heard.
It should not sound awful. If it sounds too loud and scratchy, then maybe you need to use audioop to convert from Sun .au (ulaw) to raw samples first. This was the case with the Spanish inquisition clip. -- ?!ng
"KPY" == Ka-Ping Yee <ping@lfw.org> writes:
On my machine it still sounds awful, but at least the sound can be heard.
KPY> It should not sound awful. If it sounds too loud and scratchy, KPY> then maybe you need to use audioop to convert from Sun .au KPY> (ulaw) to raw samples first. This was the case with the KPY> Spanish inquisition clip. I don't think I know how to do that. I tried using sox to convert audiotest.au to audiotest.raw and it sounded just as bad on my machine. Perhaps I have my machine configured incorrectly, although CDs and Real Audio sound fine. Have you tried the new code, BTW? Does the test work on your machine? Jeremy
Okay. I took a quick look. It's really old (July 1997). It looks like a more reasonable wrapping than linuxaudiodev, although I would want to review it more carefully against the OSS programmer's guide.
I would prefer a pure Python solution, because the code would be shorter and easier to read and maintain. It may be, however, that the ossmodule is still up-to-date; if so, it may be easier to use it than to rewrite it.
Absolutely. I just remember some announcement about it. I suspect that what I remember is not that old, so it may make sense to do a little more digging than I did in the archives... --david
I think I fixed the linuxaudio test -- see if it sounds reasonable now! The crux of the matter seemed to be that the last, optional argument to setparameters(), meaning "emulate the format if the sound card doesn't support it", is not supported right. It suppresses the error message, and the ioctl to set the format succeeds, but the emulation doesn't work (at least not on my system, or on Jeremy's). So I've used a subterfuge: assuming most sound cards support signed 16-bit native-endian format, I convert the data to that format, and use the appropriate format code: AFMT_S16_LE for little-endian machines, AFMT_S16_BE for big-endian machines. I've only tested little-endian. I use the new sys.byteorder variable to determine the endianness. I use the audioop module to do the conversion. Much simpler than sox! (Oh feeling of nostalgia... I wrote several of the file format handlers for sox, and fixed lots of bugs in it too... I even started the audio file formats FAQ, now maintained by Chris Bagwell, who also took over sox...) Downside: test_linuxaudiodev will now be skipped if you don't have the audioop enabled in your Setup file. But that's fixed easily. By the way -- the checkin freeze for the release candidate should go in just about now... --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, 6 Oct 2000, Jeremy Hylton wrote:
Have you tried the new code, BTW? Does the test work on your machine?
Works okay (i updated after Guido's last edit). Sounds fine to me. But it bugs me that some of the descriptions say "audio" and others say "format". This seems arbitrary -- is there a reason? Excerpt of Modules/linuxaudiodev.c: { 8, ������AFMT_MU_LAW, "Logarithmic mu-law audio" }, { 8, ������AFMT_A_LAW, "Logarithmic A-law audio" }, { 8,�������AFMT_U8, "Standard unsigned 8-bit audio" }, { 8, ������AFMT_S8, "Standard signed 8-bit audio" }, { 16, ������AFMT_U16_BE, "Big-endian 16-bit unsigned format" }, { 16, ������AFMT_U16_LE, "Little-endian 16-bit unsigned format" }, { 16, ������AFMT_S16_BE, "Big-endian 16-bit signed format" }, { 16, ������AFMT_S16_LE, "Little-endian 16-bit signed format" }, If you don't mind, i'd prefer something like: { 8, ������AFMT_MU_LAW, "logarithmic mu-law 8-bit audio" }, { 8, ������AFMT_A_LAW, "logarithmic A-law 8-bit audio" }, { 8,�������AFMT_U8, "linear unsigned 8-bit audio" }, { 8, ������AFMT_S8, "linear signed 8-bit audio" }, { 16, ������AFMT_U16_BE, "linear unsigned 16-bit big-endian audio" }, { 16, ������AFMT_U16_LE, "linear unsigned 16-bit little-endian audio" }, { 16, ������AFMT_S16_BE, "linear signed 16-bit big-endian audio" }, { 16, ������AFMT_S16_LE, "linear signed 16-bit little-endian audio" }, The above conforms to: <format> <width> "audio" where <format> ::= "logarithmic" ("mu-law" | "A-law") | "linear" ("unsigned" | "signed") <width> ::= "8-bit" | "16-bit" ("big-endian" | "little-endian") -- ?!ng "Simple, yet complex." -- Lenore Snell
But it bugs me that some of the descriptions say "audio" and others say "format". This seems arbitrary -- is there a reason?
Okay, you're right. (But there are sooooo many other things wrong with the code still... E.g. the bogus reference to "ctl". :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Andrew Kuchling -
David Ascher -
Guido van Rossum -
Jeremy Hylton -
Ka-Ping Yee