You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the number of issues regarding LineUnavailableException on Linux and an attempt to "fix" it, I decided dive deeper into the possible causes of the exception.
During the development of a project's audio recording modules, I came across a tutorial for capturing audio. Finding out that AudioSystem has checks for enumerating Mixers and Mixer methods for enumerating source and target DataLines, I rechecked how MultiClip was written.
Note that some lines, once closed, cannot be reopened. Attempts to reopen such a line will always result in a LineUnavailableException.
The information above was taken from the Clip Javadoc. It is possible that by using the same format causes a line to reopen, although I haven't been able to personally test this out yet.
On another point, a line that is already opened in the first place may result in an IllegalStateException, but none of the audio issues tagged here have so far reported this exception on the audio-side, so it already makes said change have no effect.
AudioSystem.isLineSupported(Line) isn't used as a check when opening a Clip
This was an oversight from #371 where I missed checking line support instead of line open. It's possible that there may be no supported audio mixers installed in the current setup (or have no audio server running, if at all present).
This is further elaborated in the next point:
Checking for presence of audio devices
Although OpenAL does check for the presence of audio devices, Clip uses Java's built-in sound system, where devices may be used by OpenAL but not to Java's own system.
Enumerating a list of Mixer objects and checking if there are any present (i.e. AudioSystem.getMixerInfo().length != 0) may be able to prevent the exception altogether (but will have no hitsound/sfx played if there are no available/supported devices).
(This research does not include JRE/JDK 9+ issues due to it being a different set of problems, unless otherwise related to the LineUnavailableException being noticed)
I'll be updating this issue with more information as I go by the development of said project's audio modules (and testing on Fedora and Mint) and a PR for testing purposes.
The text was updated successfully, but these errors were encountered:
Thanks for the research. Maybe we'll finally get to solving this.
The information in #266 might help (see also the last comment) if you haven't already seen it. I think we concluded there that it was because of a limit with open lines, and having more programs open that emit sound will make this error more likely to appear. I think ideally we'd want to mix the sound ourselves and output the mixed audio through one line, but none of us have had the time to really try.
Due to the number of issues regarding
LineUnavailableException
on Linux and an attempt to "fix" it, I decided dive deeper into the possible causes of the exception.During the development of a project's audio recording modules, I came across a tutorial for capturing audio. Finding out that
AudioSystem
has checks for enumeratingMixer
s andMixer
methods for enumerating source and targetDataLine
s, I rechecked howMultiClip
was written.Here are some of the possible points of interest:
This comment and this comment, respectively.
The information above was taken from the Clip Javadoc. It is possible that by using the same format causes a line to reopen, although I haven't been able to personally test this out yet.
If proven, it makes this change have no effect.
On another point, a line that is already opened in the first place may result in an
IllegalStateException
, but none of the audio issues tagged here have so far reported this exception on the audio-side, so it already makes said change have no effect.This was an oversight from #371 where I missed checking line support instead of line open. It's possible that there may be no supported audio mixers installed in the current setup (or have no audio server running, if at all present).
This is further elaborated in the next point:
Although OpenAL does check for the presence of audio devices,
Clip
uses Java's built-in sound system, where devices may be used by OpenAL but not to Java's own system.Enumerating a list of
Mixer
objects and checking if there are any present (i.e.AudioSystem.getMixerInfo().length != 0
) may be able to prevent the exception altogether (but will have no hitsound/sfx played if there are no available/supported devices).(This research does not include JRE/JDK 9+ issues due to it being a different set of problems, unless otherwise related to the
LineUnavailableException
being noticed)I'll be updating this issue with more information as I go by the development of said project's audio modules (and testing on Fedora and Mint) and a PR for testing purposes.
The text was updated successfully, but these errors were encountered: