> > Well, my recent ossaudiodev changes wouldn't have changed anything if > > ossaudiodev is completely hosed. However, I've finally gotten around to > > writing my pure C OSS test program. It's checked in under > > sandbox/audiotest. Please give it a try! > > > > cd nondist/sandbox > > cvs up -dP > > cd audiotest > > make && ./audiotest > > > > If *that* doesn't give sensible results, then we can't blame ossaudiodev > > for the fact that it doesn't work on your box. > > That gives sensible results. The mystery continues... > > But I wonder if there's a difference between my home and my work box? > The ossaudiodev test runs fine on my home box now, but it hung on my > work box last week; I seem to recall that it failed on my home box > before your last fix to the C module. Indeed, on my work box running ./audiotest says: opening /dev/dsp ... done audiotest: error: /dev/dsp: unable to set sample format to 8 (got 16) ls -l /dev/dsp gives: crw------- 1 guido root 14, 3 Apr 11 2002 /dev/dsp which is about the same as it is on my home box. Adding the x permission doesn't change a thing. Maybe the audio hardward on the work box simply isn't capable of doing anything besides 16-bit samples? According to hwbrowser, it is 82801AA AC'97 Audio Manufacturer: Intel Corp. Driver: i810_audio Device: N/A The home box (which works) is CRD-8400B Manufacturer: Unknown Driver: ignore Device: /dev/hdc How's that for differences. :-0 --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4