Version 2.0.6, Windows 7 64 bit
When WASAPI is selected either on main screen or in preferences window, input device list is populated with output devices and program does not go into record. When DirectSound or MME is selected, input device list is repopulated with correct input devices.
Running Rescan Audio Devices from Transport menu does not solve the problem.
That is correct. WASAPI in Audacity releases only supports recording of computer playback, so the inputs are loopbacks of the outputs. Please see: Audacity Manual.
You may need to play the stream you want to record before Audacity will start recording under WASAPI. Assuming what you are describing is that a new track opens but the recording stalls, that is not an Audacity bug. WASAPI can only record when there is already an audio “endpoint” established.
For example, an endpoint would be established if you have already used Windows Media Player to play a song.
And I think you know that, anyway. This is just for others reading this.
I have written an audio recording program based on PortAudio which can record live audio using WASAPI from a sound card or audio interface just fine.
I was instrumental in getting PortAudio to support WASAPI, in fact some of the emails from Dmitry and me may still be in the PortAudio archive. He did the coding and I did quality control. You have us to thank that PortAudio supports WASAPI at all. This was back around 2010 so PortAudio has supported WASAPI for 4 or 5 years now. Another guy had started a WASAPI implementation but gave up. Our motivation was that programs like Audacity should be able to record in 24 bits out of the box without dealing with ASIO. We had it in the back of our mind that PortAudio support of WASAPI would benefit Audacity, so it is incredible to me that Audacity doesn’t record from audio devices with WASAPI.
WASAPI for physical inputs has never been enabled in releases because there were perceived to be too many bugs. Some of them are listed here: http://bugzilla.audacityteam.org/show_bug.cgi?id=652.
Enabling WASAPI inputs in the next 2.1.0 release has not yet been totally ruled out, but doing so may give a worse experience for recording loopback inputs on some machines (which is what most Windows users care about).
I presume you build Audacity yourself with #define EXPERIMENTAL_FULL_WASAPI enabled, so you are aware of all the bugs, is that correct? Would we be able to enlist your help working on the issues?
I do agree it’s unfortunate there is no 24-bit recording ability for physical inputs. We can’t provide that with WDM-KS yet either because WDM-KS support crashes or freezes some computers as soon as Audacity is launched.
My recording program is much simpler in scope than audacity. My program does not play back so there is no loopback recording; it only records from hardware devices. It also does not manipulate levels; it records what you send it.
The problems I’ve had with WASAPI have had to do with it finding devices in Exclusive mode. WASAPI sometimes gets confused as to whether a device is present or not.
Outside of WASAPI there was a Windows problem with recording from USB devices wherein the record level control had to be turned down to 3 in the Windows control panel to achieve proper levels. That problem seems to have gone away. I don’t know if this is due to my migration to 64-bit Windows 7 or if it was fixed in a Windows update.
One has to wonder if some of these WASAPI maladies will still exist in Windows 8/8.1/8.2/10. I’m not running any of those at this time.
What kind of help are you looking for in implementing WASAPI? I do not compile Audacity myself but simply download and install it out of the box. I like Audacity’s EQ functions but prefer Goldwave for editing and use my own program for recording 24-bit audio from hardware devices.
Has any testing been done to make sure Audacity is bit perfect in 24-bit mode?
Indeed, Audacity encounters that too, but that is probably weaknesses in WASAPI or a limitation of running devices or applications in Exclusive Mode.
Microsoft themselves document that loopback recording won’t work If the application playing the audio demands exclusive access to the sound card.
Generally speaking, the consensus is that USB audio inputs are “hotter” in Vista and later than under XP and that standard Windows USB audio drivers under Vista and later add more gain than they used to. But experience varies, because I don’t have a problem on Win 7 or 8 with excessive volume in my USB devices, even using standard Windows drivers.
I haven’t seem a clear implication that the host used makes a difference.
OK. My feeling was that to the extent that any of Audacity’s problems with WASAPI are to do with its integration with PortAudio, you might be able to offer some input. Leland is the Audacity developer who has worked on WASAPI and WDM-KS, so for now I’ll just make him aware of this thread.
I don’t think we’ve done it. Others have implied 24-bit recording is correct under WASAPI and WDM-KS and not just padded 16-bit, but I don’t recall seeing detailed results.
Here’s a plug-in that could be of some help (analyse menu):
rjh-bit-depth.ny (1.17 KB)
(You can use the plug-in also on freshly imported audio to check the actual quantization)
If I generate a chirp tone and record per stereo mix, the second track shows 16 bit.
Wasapi loop back shows 32 bit float.
This implies that the recorded audio is scaled after transferring from x bit to 32 bit float.
Simple zero padding would still show 16 or 24 bit.
Example for zero padding:
- Generate a sample sound
- call the plug-in
- it shows either 32 bit float or something similar high (e.g. 26 bit)
- change the sample format (Track Dropdown menu) to either 16 or 24 bit.
- The plug-in will confirm this value.
- change back to 32 bit float (Track Dropdown menu)
- The plug-in reports still 16 or 24 bit.
That’s due to simple padding.
Former tests with Wasapi and Wdks have in fact reported 24 bit.
I can’t tell what has been altered in the implementation since.
I wrote a program which uses a walking-1 pattern to test for bit perfection. In my testing, both WASAPI and ASIO were bit perfect, as one might expect. You’re welcome to have that code but it is written in PureBasic and would have to be ported, which shouldn’t be terribly difficult to do.
I’m trying to remember how I went about calibrating USB levels but it no longer seems necessary to attenuate USB signals as previously, so I now leave the USB record level at 100 and don’t worry about it.
I brought up the issue of exclusive mode with Dmitry, who wrote the PortAudio implementation of WASAPI. He said everything was OK on his end. It’s been 5 or 6 years since I worked with Dmitry on WASAPI.
If Audacity recorded from hardware devices using WASAPI in unity gain without manipulating levels, that would be a step in the right direction. It may be that only Microsoft can fix the exclusive-mode problems.