Is the test for linuxaudiodev supposed to play the Spanish Inquistion .au file? I just realized that the test does absolutely nothing on my machine. (I guess I need to get my ears to raise an exception if they don't hear anything.) I can play the .au file and I use a variety of other audio tools regularly. Is Peter still maintaining it or can someone else offer some assistance? Jeremy
The problem is that the test file audiotest.au: Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz and the linuxaudiodev module seems to be (implicitly) expecting ".wav" format (Microsoft RIFF). If you open a .wav file and write it to the linuxaudiodev object, it works There is a function in linuxaudiodev to set audio format - there doesn't seem to be much documentation, the source has: if (!PyArg_ParseTuple(args, "iiii:setparameters", &rate, &ssize, &nchannels, &fmt)) return NULL; and when I do x = linuxaudiodev.open('w') x.setparameters(8000, 1, 8, linuxaudiodev.AFMT_MU_LAW ) I get: linuxaudiodev.error: (0, 'Error') Also tried '1' for the sample size, thinking it might be in bytes. The sample size really ought to be implicit in the format. The code in linuxaudiodev.c looks sort of dubious to me. This model is a little too simple for the variety of audio hardware and software on Linux systems. I have some homebrew audio stuff I've written which I think works better, but it's nowhere near ready for distribution. Maybe I'll clean it up and submit it for inclusion post-1.6 In the meanwhile, you could ship a .wav file for use on Linux (and Windows?) machines. (Windows doesn't usually like .au either)
"GvR" == Guido van Rossum <guido@beopen.com> writes:
I can play the .au file and I use a variety of other audio tools regularly. Is Peter still maintaining it or can someone else offer some assistance?
GvR> Does your machine have a sound card & speakers? Mine doesn't. Yes. (I bought the Cambridge Soundworks speakers that were on my old machine from CNRI.) Jeremy
Is the test for linuxaudiodev supposed to play the Spanish Inquistion .au file? I just realized that the test does absolutely nothing on my machine. (I guess I need to get my ears to raise an exception if they don't hear anything.)
Correct.
I can play the .au file and I use a variety of other audio tools regularly. Is Peter still maintaining it or can someone else offer some assistance?
Does your machine have a sound card & speakers? Mine doesn't. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Jeremy Hylton writes:
I can play the .au file and I use a variety of other audio tools regularly. Is Peter still maintaining it or can someone else offer some assistance?
The Linux audio programming docs do clearly state:
There are three parameters which affect quality (and memory/bandwidth requirements) of sampled audio data. These parameters are the following:
Sample format (sometimes called as number of bits) Number of channels (mono/stereo) Sampling rate (speed)
NOTE! It is important to set these parameters always in the above order. Setting speed before number of channels doesn't work with all devices.
linuxaudiodev.c does this: ioctl(self->x_fd, SOUND_PCM_WRITE_RATE, &rate) ioctl(self->x_fd, SNDCTL_DSP_SAMPLESIZE, &ssize) ioctl(self->x_fd, SNDCTL_DSP_STEREO, &stereo) ioctl(self->x_fd, SNDCTL_DSP_SETFMT, &audio_types[n].a_fmt) which is exactly the reverse order of what is recommended! Alas, even after fixing this, I *still* can't get linuxaudiodev to play the damned .au file. It works fine for the .wav formats. I'll continue hacking on this as time permits.
Ka-Ping Yee writes:
Side note: is there a well-defined platform-independent sound interface we should be conforming to? It would be nice to have a single Python function for each of the following things:
1. Play a .wav file given its filename.
2. Play a .au file given its filename.
These may be possible.
3. Play some raw audio data, given a string of bytes and a sampling rate.
This would never be possible unless you also specifed the format and encoding of the raw data - are they 8bit, 16-bit, signed, unsigned, bigendian, littlendian, linear, logarithmic ("mu_law"), etc? Not only that, but some audio hardware will support some formats and not others. Some sound drivers will attempt to convert from a data format which is not supported by the audio hardware to one which is, and others will just reject the data if it's not in a format supported by the hardware. Trying to do anything with sound in a platform-independent manner is near-impossible. Even the same "platform" (e.g. RedHat 6.2 on Intel) will behave differently depending on what soundcard is installed.
On Thu, 31 Aug 2000, Charles G Waldman wrote:
Alas, even after fixing this, I *still* can't get linuxaudiodev to play the damned .au file. It works fine for the .wav formats.
I'll continue hacking on this as time permits.
Just so you know -- i was definitely able to get this to work at some point before when we were trying to fix this. I changed test_linuxaudiodev and it played the .AU file correctly. I haven't had time to survey what the state of the various modules is now, though -- i'll have a look around and see what's going on. Side note: is there a well-defined platform-independent sound interface we should be conforming to? It would be nice to have a single Python function for each of the following things: 1. Play a .wav file given its filename. 2. Play a .au file given its filename. 3. Play some raw audio data, given a string of bytes and a sampling rate. which would work on as many platforms as possible with the same command. A quick glance at audiodev.py shows that it seems to support only Sun and SGI. Should it be extended? If someone's already in charge of this and knows what's up, let me know. I'm sorry if this is common knowledge of which i was just unaware. -- ?!ng
A quick glance at audiodev.py shows that it seems to support only Sun and SGI. Should it be extended?
Yes. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
On Thu, 31 Aug 2000, Charles G Waldman wrote:
3. Play some raw audio data, given a string of bytes and a sampling rate.
This would never be possible unless you also specifed the format and encoding of the raw data - are they 8bit, 16-bit, signed, unsigned, bigendian, littlendian, linear, logarithmic ("mu_law"), etc?
You're right, you do have to specify such things. But when you do, i'm quite confident that this should be possible, at least for a variety of common cases. Certainly raw audio data should be playable in at least *some* fashion, and we also have a bunch of very nice functions in the audioop module that can do automatic conversions if we want to get fancy.
Trying to do anything with sound in a platform-independent manner is near-impossible. Even the same "platform" (e.g. RedHat 6.2 on Intel) will behave differently depending on what soundcard is installed.
Are you talking about OSS vs. ALSA? Didn't they at least try to keep some of the basic parts of the interface the same? -- ?!ng
On Thu, 31 Aug 2000, Jeremy Hylton wrote:
Is the test for linuxaudiodev supposed to play the Spanish Inquistion .au file? I just realized that the test does absolutely nothing on my machine. (I guess I need to get my ears to raise an exception if they don't hear anything.)
I can play the .au file and I use a variety of other audio tools regularly. Is Peter still maintaining it or can someone else offer some assistance?
It's probably not the case, but check it isn't skipped. I've added code to liberally skip it in case the user has no permission or no soundcard. -- Moshe Zadka <moshez@math.huji.ac.il> There is no IGLU cabal. http://advogato.org/person/moshez
On 31 August 2000, Ka-Ping Yee said:
Just so you know -- i was definitely able to get this to work at some point before when we were trying to fix this. I changed test_linuxaudiodev and it played the .AU file correctly. I haven't had time to survey what the state of the various modules is now, though -- i'll have a look around and see what's going on.
I have three copies of test_linuxaudiodev.py in my Lib/test directory: the original, Ping's version, and Michael Hudson's version. I can't remember who hacked whose, ie. if Michael or Ping's is earlier. Regardless, none of them work. Here's how they fail: $ /python Lib/test/regrtest.py test_linuxaudiodev test_linuxaudiodev 1 test OK. ...but the sound is horrible: various people opined on this list, many months ago when I first reported the problem, that it's probably a format problem. (The wav/au mixup seems a likely candidate; it can't be an endianness problem, since the .au file is 8-bit!) $ ./python Lib/test/regrtest.py test_linuxaudiodev-ping test_linuxaudiodev-ping Warning: can't open Lib/test/output/test_linuxaudiodev-ping test test_linuxaudiodev-ping crashed -- audio format not supported by linuxaudiodev: None 1 test failed: test_linuxaudiodev-ping ...no sound. ./python Lib/test/regrtest.py test_linuxaudiodev-hudson test_linuxaudiodev-hudson Warning: can't open Lib/test/output/test_linuxaudiodev-hudson test test_linuxaudiodev-hudson crashed -- linuxaudiodev.error: (11, 'Resource temporarily unavailable') 1 test failed: test_linuxaudiodev-hudson ...this is the oddest one of all: I get the "crashed" message immediately, but then the sound starts playing. I hear "Nobody expects the Spani---" but then it stops, the test script terminates, and I get the "1 test failed" message and my shell prompt back. Confused as hell, and completely ignorant of computer audio, Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367
Greg Ward wrote:
...but the sound is horrible: various people opined on this list, many months ago when I first reported the problem, that it's probably a format problem. (The wav/au mixup seems a likely candidate; it can't be an endianness problem, since the .au file is 8-bit!)
Did you see the msg I sent yesterday? (Maybe I send out too many mails) I'm 99.9% sure it's a format problem, because if you replace "audiotest.au" with some random ".wav" file, it works. (On my system anyhow, with pretty generic cheapo soundblaster) The code in test_linuxaudiodev.py has no chance of ever working correctly, if you send mu-law encoded (i.e. logarithmic) data to a device expecting linear, you will get noise. You have to set the format first. And, the functions in linuxaudiodev which are intended to set the format don't work, and go against what is reccommended in the OSS programming documentation. IMHO this code is up for a complete rewrite, which I will submit post 2.0. The quick-and-dirty fix for the 2.0 release is to include "audiotest.wav" and modify test_linuxaudiodev.au. Ka-Ping Yee <ping@lfw.org> wrote:
Are you talking about OSS vs. ALSA? Didn't they at least try to keep some of the basic parts of the interface the same?
No, I'm talking about SoundBlaster8 vs. SoundBlaster16 vs. ProAudioSpectrum vs. Gravis vs. AdLib vs. TurtleBeach vs.... you get the idea. You can't know what formats are supported until you probe the hardware. Most of these cards *don't* handle logarithmic data; and *then* depending on whether you have OSS or Alsa there may be driver-side code to convert logarithmic data to linear before sending it to the hardware. The lowest-common-denominator, however, is raw 8-bit linear unsigned data, which tends to be supported on all PC audio hardware.
participants (6)
-
Charles G Waldman -
Greg Ward -
Guido van Rossum -
Jeremy Hylton -
Ka-Ping Yee -
Moshe Zadka