Thread: [Audacity-devel] Missing PortMixer in 1.3.7-beta
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Michael S. <msc...@gm...> - 2009-02-28 20:52:34
|
Is the PortMixer combo-box visible for anyone else in Audacity 1.3.7-beta with Linux? Audio Device Info debug dialog says "Unable to open Portmixer", too. |
From: Michael S. <msc...@gm...> - 2009-02-28 21:42:56
|
On Sat, 28 Feb 2009 21:52:28 +0100, Michael wrote: > Is the PortMixer combo-box visible for anyone else in Audacity 1.3.7-beta > with Linux? > > Audio Device Info debug dialog says "Unable to open Portmixer", too. The new AudioIO code is responsible for this. One must enter and save the Preferences a first time, or else the AudioIO code tries to come up with defaults that result in a -1 card index later on. |
From: Michael S. <msc...@gm...> - 2009-03-01 08:02:16
Attachments:
audacity-1.3.7-audiodevdefaults.patch
|
On Sat, 28 Feb 2009 22:42:49 +0100, Michael wrote: > On Sat, 28 Feb 2009 21:52:28 +0100, Michael wrote: > > > Is the PortMixer combo-box visible for anyone else in Audacity 1.3.7-beta > > with Linux? > > > > Audio Device Info debug dialog says "Unable to open Portmixer", too. > > The new AudioIO code is responsible for this. One must enter and save the > Preferences a first time, or else the AudioIO code tries to come up > with defaults that result in a -1 card index later on. The Audio I/O Preferences dialog does not display the default device names for the Playback/Recording devices, *if* the config file does not define the "PlaybackDevice" and "RecordingDevice" values yet. The dialog defaults to displaying the names for I/O device #0 which doesn't match the internal defaults. Attached is one patch to fix this. |
From: Markus M. <me...@me...> - 2009-03-01 19:26:21
|
Michael, thanks for the patch. I'm afraid I cannot reproduce your problem here on Windows with latest HEAD. Can you give step-by-step instructions on what must be done to reproduce your problem with a clean Audacity install? I would not recommend to apply your patch because it writes the preference from a simple "get..." function which is not supposed to have side effects like that. Instead, the locations in the code must be fixed which depend on this setting being available, allowing them to fall back to same sone behaviour gracefully. But for this, I must first reproduce your actual problem. Markus Michael Schwendt schrieb: > On Sat, 28 Feb 2009 22:42:49 +0100, Michael wrote: > >> On Sat, 28 Feb 2009 21:52:28 +0100, Michael wrote: >> >>> Is the PortMixer combo-box visible for anyone else in Audacity 1.3.7-beta >>> with Linux? >>> >>> Audio Device Info debug dialog says "Unable to open Portmixer", too. >> The new AudioIO code is responsible for this. One must enter and save the >> Preferences a first time, or else the AudioIO code tries to come up >> with defaults that result in a -1 card index later on. > > The Audio I/O Preferences dialog does not display the default device names > for the Playback/Recording devices, *if* the config file does not define > the "PlaybackDevice" and "RecordingDevice" values yet. The dialog defaults > to displaying the names for I/O device #0 which doesn't match the internal > defaults. > > Attached is one patch to fix this. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > > > ------------------------------------------------------------------------ > > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale (A. Team) <ga...@au...> - 2009-03-02 03:22:25
|
Markus Meyer wrote: > > Michael, > > thanks for the patch. I'm afraid I cannot reproduce your problem here on > Windows with latest HEAD. Can you give step-by-step instructions on what > must be done to reproduce your problem with a clean Audacity install? > > I would not recommend to apply your patch because it writes the > preference from a simple "get..." function which is not supposed to have > side effects like that. Instead, the locations in the code must be fixed > which depend on this setting being available, allowing them to fall back > to same sone behaviour gracefully. But for this, I must first reproduce > your actual problem. > > Markus What I can replicate on Windows XP with HEAD in Release (ANSI) is: 1. make sure Audacity is closed 2. Remove all content from audacity.cfg except "NewPrefsInitialized=1" and save changes 3. Launch Audacity , choose language etc. 4. Mixer Toolbar looks fine. My system default is my USB sound card set to stereo mix, and I have stereo mix in the dropdown. 5. Open Audio I/O Preferences, looks fine, I see MME: Microsoft Sound Mapper in both dropdowns 6. View > Toolbars > Check "Device Toolbar" 7. Device Toolbar appears but the boxes show white space. I can click on them and choose the proper devices from the list. 8. Exit Audacity and restart. The devices I selected last time are showing in Device Toolbar The empty-looking Device Toolbar does not stop me playing or recording. I'd add that the same happens if repeating the experiment starting 1.3.6 release after resetting cfg, so I don't know if this is a separate problem to Michael's. Gale Michael Schwendt schrieb: > On Sat, 28 Feb 2009 22:42:49 +0100, Michael wrote: > >> On Sat, 28 Feb 2009 21:52:28 +0100, Michael wrote: >> >>> Is the PortMixer combo-box visible for anyone else in Audacity >>> 1.3.7-beta >>> with Linux? >>> >>> Audio Device Info debug dialog says "Unable to open Portmixer", too. >> The new AudioIO code is responsible for this. One must enter and save the >> Preferences a first time, or else the AudioIO code tries to come up >> with defaults that result in a -1 card index later on. > > The Audio I/O Preferences dialog does not display the default device names > for the Playback/Recording devices, *if* the config file does not define > the "PlaybackDevice" and "RecordingDevice" values yet. The dialog defaults > to displaying the names for I/O device #0 which doesn't match the internal > defaults. > > Attached is one patch to fix this. > -- View this message in context: http://n2.nabble.com/Missing-PortMixer-in-1.3.7-beta-tp2402136p2407359.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Michael S. <msc...@gm...> - 2009-03-02 09:33:27
|
On Sun, 01 Mar 2009 20:26:07 +0100, Markus wrote: > Michael, > > thanks for the patch. I'm afraid I cannot reproduce your problem here on > Windows with latest HEAD. Linux. I specifically referred to Linux. > Can you give step-by-step instructions on what > must be done to reproduce your problem with a clean Audacity install? 1. delete $HOME/.audacity-data/audacity.cfg 2. start Audacity 3. notice that the PortMixer input channel combo-box is missing 3.1. open "Help > Audio Device Info" dialog 3.2. notice that: Default capture device number: 8 Default playback device number: 8 [...] Selected capture device: 8 - Selected playback device: 8 - 4. open "Edit > Preferences > Audio I/O" dialog 4.1. notice that the Playback/Recording device is set to the _first_ (!) item in each of the two listboxes 5. exit dialog with "OK" 6. notice that PortMixer appears Conclusion: Device settings have changed. Now "Audio Device Info" says: Default capture device number: 8 Default playback device number: 8 [...] Selected capture device: 0 - ALSA: Ensoniq AudioPCI: ES1371 DAC2/ADC (hw:0,0) Selected playback device: 0 - ALSA: Ensoniq AudioPCI: ES1371 DAC2/ADC (hw:0,0) Device has changed from 8 ("ALSA: default") to 0 after simply exiting the unchanged Preferences dialog with OK. 2nd conclusion: No PortMixer for recording with "ALSA: default". > I would not recommend to apply your patch because it writes the > preference from a simple "get..." function which is not supposed to have > side effects like that. True. Saving the defaults has side-effects, but it's a work-around. The real fix would make the Audio I/O Prefs retrieve the device name for the default device numbers instead of saving the defaults. |
From: Markus M. <me...@me...> - 2009-03-02 11:29:10
|
Michael, Michael Schwendt schrieb: > On Sun, 01 Mar 2009 20:26:07 +0100, Markus wrote: > Linux. I specifically referred to Linux. I would have expected the problem appears on all platforms but there must be something different going on on Linux regarding the device detection. > The real fix would make the Audio I/O Prefs retrieve the device name > for the default device numbers instead of saving the defaults. Thanks for the step-by-step directions to reproduce. I'm afraid I currently cannot reproduce the problem because I do not have a working Linux install right now. Anyone else? As you say you have an idea how a "real fix" would look like, do you think you can make up a patch for that? That would be great! Markus |
From: Michael S. <msc...@gm...> - 2009-03-02 16:39:40
Attachments:
audacity-1.3.7-audiodevdefaults.patch
|
On Mon, 02 Mar 2009 12:26:53 +0100, Markus wrote: > I would have expected the problem appears on all platforms but there > must be something different going on on Linux regarding the device > detection. Maybe. If the default I/O device index on Windows is 0, the problem won't be visible. Only if the default device index is non-zero, you should be able to reproduce it. Audacity >= 1.3.7-beta doesn't save the default preferences. However, the GUI implementation retrieves configuration values from the preferences backend (gPrefs). This creates a conflict between actual defaults and what the GUI displays as defaults in case of missing/unset preferences. E.g. the Audio I/O dialog (prefs/AudioIOPrefs.cpp -> ShuttleGUI.cpp) relies on /AudioIO/PlaybackDevice and /AudioIO/RecordingDevice being set, or else it falls back to its own default value (zero or empty string) that differs from the defaults in the Audio I/O frontend code (AudioIO.cpp). > > The real fix would make the Audio I/O Prefs retrieve the device name > > for the default device numbers instead of saving the defaults. > > Thanks for the step-by-step directions to reproduce. I'm afraid I > currently cannot reproduce the problem because I do not have a working > Linux install right now. Anyone else? > > As you say you have an idea how a "real fix" would look like, do you > think you can make up a patch for that? That would be great! I've attached a different patch, which doesn't write/save the defaults. Instead, it follows the footsteps of the current AudioIOPrefs.cpp code, which queries PortAudio to learn about devices. It's a question of design. Could still be improved by moving much more into the AudioIO.cpp wrapper instead of querying PortAudio directly. 1) It's good that defaults are _not_ saved to the cfg file. Fully agreed here. That way defaults can continue to change automatically at run-time (depending on hardware changes and/or software updates) till the user enters the Preferences dialogue and confirms/saves the settings explicitly in order to override defaults. 2) It's not good that the GUI relies on preferences being set, and if not being set, it falls back to its own defaults. As in the case of AudioIOPrefs.cpp where this fails. ShuttleGUI.cpp does not care about the actual default audio I/O device numbers as determined in AudioIO.cpp. As outlined above, it retrieves the device names from the Preferences (gPrefs). If the Preferences don't set the rec/play device, either ShuttleGUI or the AudioIOPrefs code must learn about the actual defaults as determined by AudioIO.cpp. That's what the new patch implements, except that it AudioIOPrefs queries PortAudio instead of AudioIO (which is private for most of its useful methods). |
From: Michael S. <msc...@gm...> - 2009-05-05 11:07:52
|
On Mon, 2 Mar 2009 17:39:33 +0100, Michael wrote: > I've attached a different patch, [...] While this thread had stopped at that point, cvs commit log shows major "preferences reorganization" in the affected files. Are those changes supposed to fix the bug, too? |
From: Richard A. <ric...@go...> - 2009-05-05 19:08:06
|
On Tue, 2009-05-05 at 13:07 +0200, Michael Schwendt wrote: > On Mon, 2 Mar 2009 17:39:33 +0100, Michael wrote: > > > I've attached a different patch, [...] > > While this thread had stopped at that point, cvs commit log shows > major "preferences reorganization" in the affected files. Are those > changes supposed to fix the bug, too? I don't know, I suspect it just became a victim of a bandwidth overload before Easter. Right now, it still doesn't work for me, but I haven't investigated. Leyland did do some work on Windows/Vista and merged a patch I'd had queued for years waiting for time to look at it, but that doesn't seem to have solved it here. Richard |
From: Richard A. <ric...@go...> - 2009-05-05 21:23:49
|
On Tue, 2009-05-05 at 20:07 +0100, Richard Ash wrote: > Right now, it still doesn't work for me, but I haven't > investigated. Leyland did do some work on Windows/Vista and merged a > patch I'd had queued for years waiting for time to look at it, but that > doesn't seem to have solved it here. OK, the problem now is that at the point when the toolbar is created, we haven't initialised portmixer, and so when we call AudioIO::GetInputSourceNames() it returns an empty list of inputs. I've just checked in a debug message to print out when this happens, as a reminder that it's almost certainly not what was wanted. By the time this message comes out on the console we have initialised the record and playback devices, and checked what sample rates work (I've got debug prints in that code as well). However, although we've tried to open PortMixer by this point, it didn't work. Tracing down void AudioIO::HandleDeviceChange(), about line 520 we discover that Px_OpenMixer() is called, but in the following if statement it didn't work and the function returns. So I think the true problem is with the Px_OpenMixer() call - either the wrong arguments are being passed, or the function is broken. I haven't tried to trace through portmixer to see what is going on any further. Richard |
From: Michael S. <msc...@gm...> - 2009-05-06 08:12:20
|
On Tue, 05 May 2009 22:23:34 +0100, Richard wrote: > On Tue, 2009-05-05 at 20:07 +0100, Richard Ash wrote: > > Right now, it still doesn't work for me, but I haven't > > investigated. Leyland did do some work on Windows/Vista and merged a > > patch I'd had queued for years waiting for time to look at it, but that > > doesn't seem to have solved it here. > > OK, the problem now is that at the point when the toolbar is created, we > haven't initialised portmixer, and so when we call > AudioIO::GetInputSourceNames() it returns an empty list of inputs. Well, prior to further debugging the device ids would need to be correct. That's what my 2nd patch has fixed. Whether there's one more bug in initialising portmixer remains to be seen. |
From: Leland <le...@au...> - 2009-05-09 18:08:50
|
Richard, Are you looking into this more, or would you like me to? Leland Richard Ash wrote: > On Tue, 2009-05-05 at 20:07 +0100, Richard Ash wrote: >> Right now, it still doesn't work for me, but I haven't >> investigated. Leyland did do some work on Windows/Vista and merged a >> patch I'd had queued for years waiting for time to look at it, but that >> doesn't seem to have solved it here. > > OK, the problem now is that at the point when the toolbar is created, we > haven't initialised portmixer, and so when we call > AudioIO::GetInputSourceNames() it returns an empty list of inputs. > > I've just checked in a debug message to print out when this happens, as > a reminder that it's almost certainly not what was wanted. > > By the time this message comes out on the console we have initialised > the record and playback devices, and checked what sample rates work > (I've got debug prints in that code as well). However, although we've > tried to open PortMixer by this point, it didn't work. > > Tracing down void AudioIO::HandleDeviceChange(), about line 520 we > discover that Px_OpenMixer() is called, but in the following if > statement it didn't work and the function returns. > > So I think the true problem is with the Px_OpenMixer() call - either the > wrong arguments are being passed, or the function is broken. I haven't > tried to trace through portmixer to see what is going on any further. > > Richard > > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > |
From: Richard A. <ric...@go...> - 2009-05-10 15:39:48
|
On Sat, 2009-05-09 at 13:08 -0500, Leland wrote: > Are you looking into this more, or would you like me to? I did some more work yesterday, hence the email about having two lots of portmixer.h It came to a halt however when I started reading down open_mixer() in src/px_linux_alsa.c and found the section which does sprintf(name, "hw:%d", card); There seem to me to be basic structure problems here, because back up in AudioIo.cpp where this was all called from, we didn't know what ALSA-specific card number we were dealing with - just a portaudio stream. No-where does the current code extract the device name, and it also assumes (quite possibly wrongly), that the device we are using maps to one of the hw: raw ALSA devices. Given that the default record and playback devices in Audacity should be ALSA: Default, which is an ALSA alias, I very much doubt that opening the mixer for any of the hw: devices is correct behaviour, but haven't started to read the ALSA API documentation to find out how to open the mixer associated with ALSA: Default, or what information is required to do so. The result is that right now card = -1, and so snd_mixer_attach() gets called for a mixer named "hw:-1" which fails (rightly, there is only one card in this machine, and that's hw:0). I'm not quite sure where to go from here, apart from wondering whether the ALSA API has a way to convert the ALSA device handle that portaudio already gets into a mixer handle, and whether any of this works in the case where input and output are being handled by two separate devices with separate mixers. Richard > Richard Ash wrote: > > On Tue, 2009-05-05 at 20:07 +0100, Richard Ash wrote: > >> Right now, it still doesn't work for me, but I haven't > >> investigated. Leyland did do some work on Windows/Vista and merged a > >> patch I'd had queued for years waiting for time to look at it, but that > >> doesn't seem to have solved it here. > > > > OK, the problem now is that at the point when the toolbar is created, we > > haven't initialised portmixer, and so when we call > > AudioIO::GetInputSourceNames() it returns an empty list of inputs. > > > > I've just checked in a debug message to print out when this happens, as > > a reminder that it's almost certainly not what was wanted. > > > > By the time this message comes out on the console we have initialised > > the record and playback devices, and checked what sample rates work > > (I've got debug prints in that code as well). However, although we've > > tried to open PortMixer by this point, it didn't work. > > > > Tracing down void AudioIO::HandleDeviceChange(), about line 520 we > > discover that Px_OpenMixer() is called, but in the following if > > statement it didn't work and the function returns. > > > > So I think the true problem is with the Px_OpenMixer() call - either the > > wrong arguments are being passed, or the function is broken. I haven't > > tried to trace through portmixer to see what is going on any further. > > > > Richard |
From: Leland <le...@au...> - 2009-05-10 18:28:25
|
Richard Ash wrote: > On Sat, 2009-05-09 at 13:08 -0500, Leland wrote: >> Are you looking into this more, or would you like me to? > I did some more work yesterday, hence the email about having two lots of > portmixer.h It came to a halt however when I started reading down > open_mixer() in src/px_linux_alsa.c and found the section which does > sprintf(name, "hw:%d", card); > > There seem to me to be basic structure problems here, because back up in > AudioIo.cpp where this was all called from, we didn't know what > ALSA-specific card number we were dealing with - just a portaudio > stream. No-where does the current code extract the device name, and it > also assumes (quite possibly wrongly), that the device we are using maps > to one of the hw: raw ALSA devices. Given that the default record and > playback devices in Audacity should be ALSA: Default, which is an ALSA > alias, I very much doubt that opening the mixer for any of the hw: > devices is correct behaviour, but haven't started to read the ALSA API > documentation to find out how to open the mixer associated with ALSA: > Default, or what information is required to do so. > > The result is that right now card = -1, and so snd_mixer_attach() gets > called for a mixer named "hw:-1" which fails (rightly, there is only one > card in this machine, and that's hw:0). I'm not quite sure where to go > from here, apart from wondering whether the ALSA API has a way to > convert the ALSA device handle that portaudio already gets into a mixer > handle, and whether any of this works in the case where input and output > are being handled by two separate devices with separate mixers. > In px_mixer.c, we call OpenMixer_Linux_ALSA() which then calls PaAlsa_GetStreamInputCard() and PaAlsa_GetStreamOutputCard(). These last two return the value snd_pcm_info_get_card(). This is where the "-1" would be coming from as the alsa doc says that the returned value will be "a negative error code if not associable to a card." Seems we should be checking the returned value from PaAlsa*Card() for negative values and complaining. But, that doesn't solve your issue... Why is snd_pcm_info_get_card() returning an error??? I'll see if I can recreate it here. Leland |
From: Martyn S. <mar...@go...> - 2009-05-10 21:05:41
|
Hi there I don't know if you saw my post about getting Audacity working on Portable Ubuntu, but the patch to fix it 'may' be related to this problem http://cvs.fedoraproject.org/viewvc/rpms/audacity/devel/audacity-1.3.7-portaudio-non-mmap-alsa.patch?revision=1.3&view=markup I was also pointed at another patch by by Michael Schwendt http://cvs.fedoraproject.org/viewvc/rpms/audacity/devel/audacity-1.3.7-audiodevdefaults.patch?revision=1.2&view=markup which is in the same area again. Sorry if this isn't useful Martyn Leland wrote: > Richard Ash wrote: >> On Sat, 2009-05-09 at 13:08 -0500, Leland wrote: >>> Are you looking into this more, or would you like me to? >> I did some more work yesterday, hence the email about having two lots of >> portmixer.h It came to a halt however when I started reading down >> open_mixer() in src/px_linux_alsa.c and found the section which does >> sprintf(name, "hw:%d", card); >> >> There seem to me to be basic structure problems here, because back up in >> AudioIo.cpp where this was all called from, we didn't know what >> ALSA-specific card number we were dealing with - just a portaudio >> stream. No-where does the current code extract the device name, and it >> also assumes (quite possibly wrongly), that the device we are using maps >> to one of the hw: raw ALSA devices. Given that the default record and >> playback devices in Audacity should be ALSA: Default, which is an ALSA >> alias, I very much doubt that opening the mixer for any of the hw: >> devices is correct behaviour, but haven't started to read the ALSA API >> documentation to find out how to open the mixer associated with ALSA: >> Default, or what information is required to do so. >> >> The result is that right now card = -1, and so snd_mixer_attach() gets >> called for a mixer named "hw:-1" which fails (rightly, there is only one >> card in this machine, and that's hw:0). I'm not quite sure where to go >> from here, apart from wondering whether the ALSA API has a way to >> convert the ALSA device handle that portaudio already gets into a mixer >> handle, and whether any of this works in the case where input and output >> are being handled by two separate devices with separate mixers. >> > In px_mixer.c, we call OpenMixer_Linux_ALSA() which then calls > PaAlsa_GetStreamInputCard() and PaAlsa_GetStreamOutputCard(). These > last two return the value snd_pcm_info_get_card(). This is where the > "-1" would be coming from as the alsa doc says that the returned value > will be "a negative error code if not associable to a card." Seems we > should be checking the returned value from PaAlsa*Card() for negative > values and complaining. > > But, that doesn't solve your issue... > > Why is snd_pcm_info_get_card() returning an error??? > > I'll see if I can recreate it here. > > Leland > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |