search

dagargo / overwitch

JACK client for Overbridge devices
GNU General Public License v3.0
139 stars 18 forks source link

Watch/autorun mode #27

Closed szszoke closed 2 years ago

szszoke commented 2 years ago

I am wondering if there would be any interest for a watch/autorun mode which would essentially start an Overwitch client instance for every supported device that is connected.

This might not make much sense for Jack because most people would not have Jack running all the time on their computer, but for those who run PipeWire, it could be useful.

This would essentially make Overwitch devices behave the same way a regular USB sound card would when it comes to PipeWire: device connected -> device shows up in PipeWire.

dagargo commented 2 years ago

Is the GUI refresh button good enough for this?

I think that this watching system makes sense for graphical environments but as you would loose control over the background process I'm not sure if it's a good idea.

For embedded systems without a GUI, I don't like it as it will always imply a consequent action (i. e. recording to disk or streaming to another interface), so it's the user of those systems who I think should create this specific watching system.

What do you think?

szszoke commented 2 years ago

I'm going to play around with the UI and then answer your question.

dagargo commented 2 years ago

Any update on this?

What are your thoughts regarding UI/UX?

szszoke commented 2 years ago

Sorry! I didn't have time to look at this closely but I will try to give feedback sometime this week.

dagargo commented 2 years ago

No worries. We're not in a hurry.

szszoke commented 2 years ago

I played around with it a bit and here are some remarks:

  1. It would be nice if the refresh button would just refresh the list of available devices, and there would be a separate button, maybe for each row individually, that would start/stop Overwitch for the discovered devices. There could be a "start/stop all" button as well.

  2. What does blocks do and why would I want to change it?

  3. Would it make sense to set the blocks/quality individually for each discovered device?

  4. Is there a way to know when tuning for a device is done and playback/recording should be ready? Something like a Status column that says one of the following Stopped, Tuning, Ready, Error?

I also managed to crash it by pressing the stop and refresh button back to back. After 4-5 rounds of this the app crashed with a non-descriptive segmentation fault.

0x00007ffff6b05bcc in pw_thread_loop_stop () from /usr/lib/libpipewire-0.3.so.0

I suppose it could be caused by PipeWire alone.

Closing the app also results in a segfault sometimes.

dagargo commented 2 years ago

I suppose it could be caused by PipeWire alone. Closing the app also results in a segfault sometimes.

It was a bug. It's fixed now.

Also, I've added the status as the first column in the devices list as you suggested

For now, I'm not gonna change the behaviour of the blocks and quality widgets or add them to the rows. However, now it's not possible to change the values unless there are no devices running. I think it was confusing so I changed it.

BTW, the amount of blocks the amount of data (audio and MIDI) passed on each burst to the devices. The lower, the smaller latency. t In my mind, the typical use case is to configure the desired parameters and to start all devices at boot.

Let me know your thoughts on all this.

szszoke commented 2 years ago

I will take another look.

In the meantime, I think a tooltip with a short description of what Block size and Quality does, and what the consequences of different values are would be a nice way to educate users.

szszoke commented 2 years ago

It doesn't seem to crash now.

dagargo commented 2 years ago

In the meantime, I think a tooltip with a short description of what Block size and Quality does, and what the consequences of different values are would be a nice way to educate users.

Done in b61346d463d13addba2b28ff028c355a18fb4deb.

dagargo commented 2 years ago

I'm closing this as not it's not going to be implemented.

For embedded devices, a small service to run overwitch-cli could be used. OTOH, for desktop environments, the GUI is enough and, IMO, adding a service would be unnecessary. After all, Overwitch is just a JACK plugin. Perhaps adding a plugin definition for JACK or Ardour could be useful but being a multitrack device I don't know if there is a way to add this without being confusing.