Skip Montanaro write:
Neil Schemenauer replied:
Something has /dev/dsp or /dev/audio open. Are you playing MP3s or running something like esd?
If another process was holding /dev/whatever open, it's hard to understand how the agonizing wail was produced. The code in linuxaudiodev does its initializations in an order which is explicitly proscribed by the OSS programming guide. I have a SWIG-based linux audio module that I use in my code, not wanting anything to do with the (to me) highly suspect linuxaudiodev module. Should I dust off this code and contribute it? Of course, if we really want to provide high-quality audio support on Linux, we have to account for a number of different options - at least, OSS and ALSA... this is sort of a can-of-worms. But I do believe that the current linuxaudiodev module should be deprecated.
Sure. Do you want to take the lead here? Nobody at PythonLabs has any interest in this, and without someone putting a stake into the ground, there's no point in even talking about it. It sounds you know what you're talking about, and you have CVS permission, so if you want to do it, go ahead. (For b/w compatibility we may have to keep the linuxaudio extension around for a while, in a deprecated state.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
Would it make sense to include a Python implementation that wraps aronud whatever low-level modules are needed? Or to use the same API and just replace the implementation? I don't know enough about the potential replacements, but it would be nice to maintain the availability of the API; it's been available for several versions now. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
"GvR" == Guido van Rossum <guido@zope.com> writes:
GvR> Sure. Do you want to take the lead here? Nobody at GvR> PythonLabs has any interest in this, and without someone GvR> putting a stake into the ground, there's no point in even GvR> talking about it. It sounds you know what you're talking GvR> about, and you have CVS permission, so if you want to do it, GvR> go ahead. I have interest, but no time. Although I'm sure Charles can do everything necessary on his own, if he needs help from inside Pythonlabs I'll volunteer. -Barry
Charles> I have a SWIG-based linux audio module that I use in my code, Charles> not wanting anything to do with the (to me) highly suspect Charles> linuxaudiodev module. Should I dust off this code and Charles> contribute it? Charles> Of course, if we really want to provide high-quality audio Charles> support on Linux, we have to account for a number of different Charles> options - at least, OSS and ALSA... this is sort of a Charles> can-of-worms. But I do believe that the current linuxaudiodev Charles> module should be deprecated. Charles, is your SWIG-based thing still Linux-specific? (I sort of suspect it is.) While having to support multiple options will be a pain, I think they will each tend to be more platform-neutral than the current approach. Skip
Sure. Do you want to take the lead here? Nobody at PythonLabs has any interest in this, and without someone putting a stake into the ground, there's no point in even talking about it. It sounds you know what you're talking about, and you have CVS permission, so if you want to do it, go ahead. (For b/w compatibility we may have to keep the linuxaudio extension around for a while, in a deprecated state.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
Would it make sense to include a Python implementation that wraps aronud whatever low-level modules are needed? Or to use the same API and just replace the implementation? I don't know enough about the potential replacements, but it would be nice to maintain the availability of the API; it's been available for several versions now. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
"GvR" == Guido van Rossum <guido@zope.com> writes:
GvR> Sure. Do you want to take the lead here? Nobody at GvR> PythonLabs has any interest in this, and without someone GvR> putting a stake into the ground, there's no point in even GvR> talking about it. It sounds you know what you're talking GvR> about, and you have CVS permission, so if you want to do it, GvR> go ahead. I have interest, but no time. Although I'm sure Charles can do everything necessary on his own, if he needs help from inside Pythonlabs I'll volunteer. -Barry
Charles> I have a SWIG-based linux audio module that I use in my code, Charles> not wanting anything to do with the (to me) highly suspect Charles> linuxaudiodev module. Should I dust off this code and Charles> contribute it? Charles> Of course, if we really want to provide high-quality audio Charles> support on Linux, we have to account for a number of different Charles> options - at least, OSS and ALSA... this is sort of a Charles> can-of-worms. But I do believe that the current linuxaudiodev Charles> module should be deprecated. Charles, is your SWIG-based thing still Linux-specific? (I sort of suspect it is.) While having to support multiple options will be a pain, I think they will each tend to be more platform-neutral than the current approach. Skip
participants (5)
-
barry＠zope.com -
Charles G Waldman -
Fred L. Drake, Jr. -
Guido van Rossum -
Skip Montanaro