Bugs item #1566331, was opened at 2006-09-27 13:19 Message generated for change (Comment added) made by rluse You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Dennis (samdennis) Assigned to: Greg Ward (gward) Summary: Bad behaviour in <ossaudio audio device>.obuf* Initial Comment: The _ssize() function in ossaudiodev.c (2.4.3, but it's the same in svn) calls SNDCTL_SET_CHANNELS with channels=0 as part of an attempt to determine the total number of samples per second for the current configuration of the audio device, but as far as I can tell this is not guaranteed to act as a query and at least two implementations treat it as a request for a monaural format (the ALSA pcm-oss module and the alsa-oss library). What this can safely be replaced with I don't know; both Linux's OSS drivers and ALSA support SOUND_PCM_READ_CHANNELS but this is not standard to the best of my knowledge. Storing the value returned when the program calls .setfmt or .setparameters may be an option. ---------------------------------------------------------------------- Comment By: Bob Luse (rluse) Date: 2007-05-06 03:41 Message: Logged In: YES user_id=1688601 Originator: NO I just wanted to confirm that this is problem for me as well when I run this. I am writing an application where I need to get buffer information when I am running with 2 channels. This is a quite normal situation these days. I assume that the change is made to mono because in OSS mono is the default, so that it will work with what is now quite ancient hardware. But, requesting the buffer size should not cause such a dramatic error. I don't understand why this is such a problem. Could there be a parameter for number of channels since you cannot request the buffer size unless you have already setup the hardware giving the number of channels? So even if the System cannot figure out the number of channels, your application knows it and can tell it. Granted, it is a kluge, but it is a kluge that can work whereas currently whenever you request buffer information the speed of your sound is cut in half making the obuf commands unusable. Possibly another solution would be to remove these commands until they work. I did notice that the program does reference SOUND_PCM_WRITE_CHANNELS. Is SOUND_PCM_WRITE_CHANNELS standard and SOUND_PCM_READ_CHANNELS not standard? I don't know that that is not true, but it does seem strange. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
