This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rluse
Recipients
Date 2007-05-06.03:41:30
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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.  
History
Date User Action Args
2007-08-23 14:43:08adminlinkissue1566331 messages
2007-08-23 14:43:08admincreate