The problem is easy to reproduce and is down to this line in AudioIO::StartStream

   if( playbackTracks.GetCount() > 0 )
      playbackChannels = 2;

 ----
 SNIP SNIP SNIP SNIP
 ----

   bool successAudio;

   successAudio = StartPortAudioStream(sampleRate, playbackChannels,
                                       captureChannels, captureFormat);


Setting playbackChannels to 1 cures the problem and I get playback through my headset.

I tried 1.3.3 beta and got exactly the same problem.

(In reply to comment #1)
I'm puzzled though why so many of the complainants claim they don't have
the same problem in 1.3.3. There is an example here:
http://forum.audacityteam.org/viewtopic.php?f=17&t=18280&start=0

but the comment about it "working in 1.3.3" has been consistent. Clearly 
that code hasn't changed in the interim. And since I know of Windows
users with Bluetooth headsets that have no problem, Mac behaviour 
must be figured in here somewhere? 

Have you been into Audio MIDI setup and set the headset up as mono?
A few people say this fixes it, but most don't.

(In reply to comment #2)
It may be that my headset has never worked with any version but I definitely I get the error with the 1.3.3 beta DMG from the downloads section.  This isn't surprising as it's exactly the same code as in my previous comment.

I checked Audio MIDI setup and my headset was already set as mono.

I'll try and look at this further over the weekend but it appears that the call to StartPortAudioStream needs playbackChannels set to 1 for mono devices.

(In reply to comment #3)
Could you perhaps put a build up somewhere that has playback channels set to "1"? That might give us an idea if this is going to fix it in SVN for people whose headset does work in 1.3.3. 

So what we have to do (in layman's terms)is to set playback channels to 1 when Audacity's playback device is detected as having output channels =1?

This makes sense - I remember reading this code and realising that the number of output channels was hard-coded to 2 (stereo), but assuming that as all sound cards are stereo or more this wouldn't be a problem (this was before bluetooth was invented).

Given we want a minimum-invasive fix for cases with just one and two channels, we could just check the maxOutputChannels member of the Pa_DeviceInfo structure before opening the device, and if it's 1 (which I hope it is for the problem set-ups, you can check via the Help > Audio Device Info window) then only open for mono output.

We do have to do a bit more however to make this sensible:
1) We need to mix the project in mono rather than stereo. I think this just means flags to the mixer class, as for when we export to a mono file.
2) It would be good to make it visible at run time. My suggestion is that we add the information to the message in the bottom right that reports the actual sample rate used (could just append M or S, it's only really there for debugging / support).

I added this in to AudioIO::StartStream as a test and it appeared to work.

It could probably do with some beautification though.

   if( playbackTracks.GetCount() > 0 )
   {
      PaStreamParameters *playbackParameters = NULL;
      playbackParameters = new PaStreamParameters;
      playbackParameters->device = getPlayDevIndex();
      
      const PaDeviceInfo *playbackDeviceInfo;
      playbackDeviceInfo = Pa_GetDeviceInfo( playbackParameters->device );
      
      if ( playbackDeviceInfo == NULL )
      {
         playbackChannels = 2;
      }
      
      else
      {
         playbackChannels = playbackDeviceInfo->maxOutputChannels;
      }
   }

(In reply to comment #6)
Paul wrote:
> I added this in to AudioIO::StartStream as a test and it appeared to work.
Can you make a patch against HEAD and attach?

Richard's suggestions about mixing in mono and the M/S in the Status Bar seem to be good to me. 

Where I have info, all the complainants who find their Bluetooth devices work in 1.3.3 but not later versions have stereo devices, so I suspect the reason for that issue is something else altogether.

No activity here in 6 years. I updated the release note to remove the advice to revert to 1.3.3 and updated the link for Soundflower. I do not have USB headset so cannot test using Soundflower as a workaround.
There has recently (Aug 13 2017) been a report of this problem on the forum

http://forum.audacityteam.org/viewtopic.php?p=332290#p332290

A report from Flavio P. Ribeiro via feedback@ added this information:

"I’ve recently tested Audacity with a custom USB audio device which only supports mono playback. This resulted in an error from what appears to be bug 167. As comment 1 describes, Audacity hardcodes the number of playbackChannels to 2. Hardcoding it to 1 is not enough to fix, because the two channel assumption is used elsewhere in the code."

Testing with 2.3.2 on macOS 10.14.5 using our Rokono F10 Bluetooth speaker.

The speaker connects to the Mac just fine with Bluetoot and can be selected as the output device in Audacity with no error message.  


I plays OK withot any error message,

If I power off the speaker I get
>Error opening sound device
which is only to be expected


I can only presume there are some bad Bluetooth speakers out there - or folk don't know how to configure them correctly

The workaround provided is out of date as SoundFlower is deprecated EOL

It is not being developed any more, but still works fine so IMO is still a valid work around.

There is also iShowU Audio Capture that works on a Mac. Not sure if it works on other platforms.