Liquidsoap

Update or drop liguidsoap

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

Liguidsoap does not currently work. We should either really update it, or remove it from the distribution.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Baelde added a comment -
I've started doing some easy updates and it works better. I can't commit right now but will do soon.

One of the issues though is that by default liquidsoap will currently try to use pulse and portaudio I/O (utils.liq, definitions of in() and output.prefered()) that may also need an "update or drop". I plan to update those two definitions so that (1) ALSA and OSS have the highest priority (at least I can tell they can work) and (2) in() and output.prefered() rely on the same clock. I'm also thinking of renaming in() into input.prefered().
Show
David Baelde added a comment - I've started doing some easy updates and it works better. I can't commit right now but will do soon. One of the issues though is that by default liquidsoap will currently try to use pulse and portaudio I/O (utils.liq, definitions of in() and output.prefered()) that may also need an "update or drop". I plan to update those two definitions so that (1) ALSA and OSS have the highest priority (at least I can tell they can work) and (2) in() and output.prefered() rely on the same clock. I'm also thinking of renaming in() into input.prefered().
Hide
Permalink
Romain Beauxis added a comment -
output.pulse works very nicely and we actually have an external contributor for ocaml-portaudio!

With all the issues regarding alsa when pulseaudio is installed, I would recommend to use pulse by default when it is available in the system. Of course, I have no idea how to detect whether or not it is available...
Show
Romain Beauxis added a comment - output.pulse works very nicely and we actually have an external contributor for ocaml-portaudio! With all the issues regarding alsa when pulseaudio is installed, I would recommend to use pulse by default when it is available in the system. Of course, I have no idea how to detect whether or not it is available...
Hide
Permalink
David Baelde added a comment -
Yes, the more precise point is that the current definitions, that favorizes portaudio and pulse as soon as they are supported by liquidsoap, is bad because it does not check that they are actually usable. Same suggestion: put OSS and ALSA last so they get priority (here, ALSA has repetitive xrun and OSS does not so I prefer it... but I didn't test how it actually behaves yet). Perhaps we should find another policy that forces users to set a reasonable preference...
Show
David Baelde added a comment - Yes, the more precise point is that the current definitions, that favorizes portaudio and pulse as soon as they are supported by liquidsoap, is bad because it does not check that they are actually usable. Same suggestion: put OSS and ALSA last so they get priority (here, ALSA has repetitive xrun and OSS does not so I prefer it... but I didn't test how it actually behaves yet). Perhaps we should find another policy that forces users to set a reasonable preference...
Hide
Permalink
Romain Beauxis added a comment -
Ideally, we should disable output.xx if xx is not present in the system..
Show
Romain Beauxis added a comment - Ideally, we should disable output.xx if xx is not present in the system..
Hide
Permalink
David Baelde added a comment -
It's hard to detect what is available. The default device or port may not be found, but a user-specified one may work. Hence it'd be abusive to disable output.x if x appears to be unavailable. The same reasoning shows that our naive "preference" system doesn't work well enough.

A better solution would be to: (1) Always enable all supported I/O, as it is the case currently. (2) Have a prefered input/output that is always available, and has a different implementation depending on a detection done at runtime: if the default ALSA device seems to work, we can use ALSA I/O; if pulseaudio is available with default settings, we can use it; if everything fails, pick a dummy implementation; etc. Unfortunately this requires a little bit of code, including a system of detection plugins. If detection is done upon instantiation of output.prefered() we can rely on a setting to tweak the detection order. Detection results should be cached to ensure consistency -- all input/output.prefered should rely on the same soundcard API and clock.
Show
David Baelde added a comment - It's hard to detect what is available. The default device or port may not be found, but a user-specified one may work. Hence it'd be abusive to disable output.x if x appears to be unavailable. The same reasoning shows that our naive "preference" system doesn't work well enough. A better solution would be to: (1) Always enable all supported I/O, as it is the case currently. (2) Have a prefered input/output that is always available, and has a different implementation depending on a detection done at runtime: if the default ALSA device seems to work, we can use ALSA I/O; if pulseaudio is available with default settings, we can use it; if everything fails, pick a dummy implementation; etc. Unfortunately this requires a little bit of code, including a system of detection plugins. If detection is done upon instantiation of output.prefered() we can rely on a setting to tweak the detection order. Detection results should be cached to ensure consistency -- all input/output.prefered should rely on the same soundcard API and clock.
Hide
Permalink
David Baelde added a comment -
We should try to close this branch before the beta2. LiGuidsoap may be useful, and it is at least a good demo of how to use liquidsoap as a backend. We don't have to work out a full solution for prefered I/O detection: the minor enhancement that I did may be enough (?) or we could provide users with a choice in liGuidsoap (in which case input/output.prefered may be dropped completely).

Regarding the subtask, I find it unrelated. Anyway I suggest to dismiss it: for now it is unconvinced, and even a bad idea in my opinion. Eventually, we'll find a general redesign for interaction, that will apply in particular to the mixer.
Show
David Baelde added a comment - We should try to close this branch before the beta2. LiGuidsoap may be useful, and it is at least a good demo of how to use liquidsoap as a backend. We don't have to work out a full solution for prefered I/O detection: the minor enhancement that I did may be enough (?) or we could provide users with a choice in liGuidsoap (in which case input/output.prefered may be dropped completely). Regarding the subtask, I find it unrelated. Anyway I suggest to dismiss it: for now it is unconvinced, and even a bad idea in my opinion. Eventually, we'll find a general redesign for interaction, that will apply in particular to the mixer.
Hide
Permalink
David Baelde added a comment -
Fixed in branch LS-496 and 496b, merged in default with 495f4a73b3d5.
Show
David Baelde added a comment - Fixed in branch LS-496 and 496b, merged in default with 495f4a73b3d5.
Hide
Permalink
David Baelde added a comment -
It is updated, ready to be shipped with the beta2 release.
Show
David Baelde added a comment - It is updated, ready to be shipped with the beta2 release.

People

  • Assignee:
    David Baelde
    Reporter:
    Samuel Mimram
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: