Bug 245 - Plugging in headphones or enumeration change in hardware stops audio output
Summary: Plugging in headphones or enumeration change in hardware stops audio output
Status: ASSIGNED
Alias: None
Product: LinuxSampler
Classification: Unclassified
Component: drivers (show other bugs)
Version: 2.0.0
Hardware: Macintosh Mac OS X 10.10 (Yosemite)
: P5 major
Assignee: Christian Schoenebeck
URL:
Depends on:
Blocks:
 
Reported: 2015-11-04 12:00 CET by Maurits Lamers
Modified: 2016-07-25 18:23 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maurits Lamers 2015-11-04 12:00:01 CET
I recently discovered LinuxSampler also ran on Mac OSX natively, which solves a lot of issues for me, not in the least since Apple has stopped shipping MIDI file playing support in OSX.
I therefore use LinuxSampler as a stand alone midi player in combination with Frescobaldi (the Lilypond editor).

I am however encountering some issues with LinuxSampler, especially regarding the loss of audio output.

Under Mac OSX the audio hardware identification is enumerated, leading to identifiers as "1 Built-in Output". This enumeration is prone to changes, especially on laptops, because the list will be refreshed whenever an event takes place, such as entering a WLAN area with airplay capabilities. Identifiers like "1 Built-in Output" will become "2 Built-in Output".

I suspect the same issue is also taking place whenever headphones are plugged in, though I haven't been able to see a difference in the audio destination selection in qsampler.

In both cases, the sampler looses its audio output completely. This loss of audio happens without any warning or error message. 

In the case of the head phones, unplugging them won't bring the audio output back.
The only solution is to completely shut down the linux sampler as well as the qsampler program, and restart.

In the case of enumeration changes, the workaround is more complex. Because the full id of the audio hardware is stored in a session file (the lscp file), this also causes issues for loading previous sessions, because the sampler will try to set up the session for a device which might not exist, especially when the enumerated list has changed since the session file was created. In those cases it is necessary to manually edit the lscp file and restart the entire system in order to have the audio output back.