Open mixxxbot opened 2 years ago
mixxxbot
commented
2 years ago Commented by: rryan Date: 2013-04-24T15:35:11Z
Since we use JACK through PortAudio there are limitations in how we can interact with JACK. We should work with PortAudio to expose more of the JACK API.
mixxxbot
commented
2 years ago Commented by: Michael-Z-Freeman Date: 2013-04-25T13:23:22Z
Would it be helpful if I filed a bug with Portaudio ?
Are you using Portaudio to make cross compiling easier ? When I last checked Jack Audio Connection Kit was in very early development on Windows and I'm not even sure how many or even if people use Jack on Windows. Would it make more sense to reserve Jack support for Linux ? That might make development of Jack for Mixxx easier.
mixxxbot
commented
2 years ago Commented by: rryan Date: 2013-04-25T13:50:05Z
It's partly for cross-platform support but mostly so we do not have to support every API in Mixxx since PortAudio is a wrapper around each individual OS's set of APIs (ALSA, OSS, JACK, DirectSound, ASIO, WASAPI, WDMKS, CoreAudio, etc.). We would greatly prefer to solve this within PortAudio rather than adding back in dedicated JACK support.
The problem is I don't have a solid description of what needs to change in PortAudio so I'm not sure what your bug report would say.
On Thu, Apr 25, 2013 at 9:23 AM, DJ_Barney
Would it be helpful if I filed a bug with Portaudio ?
Are you using Portaudio to make cross compiling easier ? When I last checked Jack Audio Connection Kit was in very early development on Windows and I'm not even sure how many or even if people use Jack on Windows. Would it make more sense to reserve Jack support for Linux ? That might make development of Jack for Mixxx easier.
-- You received this bug notification because you are a member of Mixxx Development Team, which is subscribed to Mixxx. https://bugs.launchpad.net/bugs/1172299
Title: Jack Audio Connection Kit Implementation Does not Follow Normal Behaviour
To manage notifications about this bug go to: https://bugs.launchpad.net/mixxx/+bug/1172299/+subscriptions
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2013-04-25T15:30:20Z
I have just read into JACK and Portaudio API.
I am afraid that the quested function is out of scope of Portaudio.
Port audio is a simple wrapper around many APIs for a common interface. The requested function, to expose static audio port to Jack, is a particularly Jack function. Once Implemented in Port audio it is only suitable for Jack.
But you can give it a try on the portaudio mailing list <email address hidden>.If I have understand it right, there are two classes of Jack applications:
1) Instant port applications with self connecting like Mixxx/Portaudio
2) Static port applications like Meterbridge
Portaudio (1) is Looking for exposed Jack ports and registers the counter port instantly on connection. This way there is no external connection tool required. But if the Portaudio app is not connected it has no ports.
Meterbridge (2) does nothing without any connection but exposes all its ports to Jack just after startup.
But it is possible to trick Mixxx, if you create Mixxx Jack ports by connecting to random jack ports from the Mixxx config GUI. And then change the connection by an external connection tool.
http://dis-dot-dat.net/index.cgi?item=/jacktuts/starting/
I think th Jack API is really easy. And since Jack is also OS independent it should be not hard to Implement a native SoundDeviceJack. But it is a lot of work anyway. We can toggle between our own hardware connection dialog and Simply expose all Mixxx Ports to jack.
mixxxbot
commented
2 years ago Commented by: Michael-Z-Freeman Date: 2013-04-26T17:26:34Z Attachments: mixxx_jack_output_preferences.png
Thanks for your confirmation RJ Ryan. I looked at some of the Mixxx code and into how Portaudio handles the ports. I'll take this to the Portaudio dev team when I can. I'll probably start with the numbering from zero.
So, thanks as well daschuer. By the look of it the Portaudio names HAVE to be "out_0, Out_1, ...", but at least we have the Mixxx client properly named now (I forgot I'd put in this bug that got that fixed :) - https://bugs.launchpad.net/mixxx/+bug/839547 ... This fixed the Jack client name from Portaudio to Mixxx.
The only other possiblity is if the Portaudio ports CAN simply ONLY BE OPENED in Jack, is there any way round Portaudio always forcing the connections ? Then they would instantly appear when Jack is selected in the drop down Sound API selection. But, if thats possible, then we seem to be in a catch 22 as all the ports can only be named (I think) "out_0, Out_1, ..." and its difficult for the user to find out what ports match to "Master, Headphones, Deck 1, Deck2, Vinyl Control 1, Vinyl Control 2, Microphone" ... BUT ... and maybe I just solved it. What if those port names, "out_0, Out_1, ...", are automatically filled in next to the Mixx input/output names in the Mixxx Sound Hardware Preferences API ?
Failing that maybe Mixxx could just give Portaudio ALL its inputs and outputs and let Portaudio do its stuff in Jack WITHOUT asking the user anything ? Then have the port numbers shown in the Mixxx GUI which gets round the naming confusion and would appear to be a more straight forward way of doing this more in line with normal Jack behaviour.
SEE ATTACHEMENTS FOR GUI MOCKUP
mixxxbot
commented
2 years ago Commented by: Michael-Z-Freeman Date: 2013-04-26T17:28:06Z Attachments: mixxx_jack_input_preferences.png
Second attachment ...
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2013-04-26T21:52:11Z
Hi Barney,
the Mixxx ports in Jack are instant ports created as counterparts to the connected ports. It is not intended to reconnect them by external Jack connection tools. So I am afraid your ideas are misleading.
If you have programming experience and bored from the TV programm ;-). I can give you a hand writing a SoundDeviceJack class. This is the best way to solve this issue.The config GUI will just have a additional SondDevice selector:
mixxxbot
commented
2 years ago Commented by: rryan Date: 2013-04-26T22:10:44Z
On Fri, Apr 26, 2013 at 5:52 PM, Daniel Schürmann <
<email address hidden>> wrote:Hi Barney,
the Mixxx ports in Jack are instant ports created as counterparts to the connected ports. It is not intended to reconnect them by external Jack connection tools. So I am afraid your ideas are misleading.
If you have programming experience and bored from the TV programm ;-). I can give you a hand writing a SoundDeviceJack class. This is the best way to solve this issue.
Yet again the Mixxx codebase goes in circles :). We used to have a sound device for every API but PortAudio allowed us to rid ourselves of the maintenance work of managing each individual one.
I really don't want to be back in the business of writing Sound API-specific code (We were also talking about a PulseAudio SoundDevice to get rid of pasuspender on Ubuntu!). Sure, each individual API seems simple enough but when you add it all up it is way too much code to maintain. We should check with PortAudio to make sure they won't support what we want (the ability to create a device / endpoint in the case the API supports it).
Also, I think there still may be some lingering assumptions about PortAudio in SoundManager (other than the giant sections of ifdef's specific to portaudio). We'll need to make sure it is truly generic.
The config GUI will just have a additional SondDevice selector:
- Portaudio: like it is.
- Jack:
I think there's no reason to expose this detail to the user -- they surely don't care. We could just make the API list of strings internally represented by a (sound-device, API) tuple, so the intenral state of hte API dropdown on linux would look like:
(PA, ALSA), (PA, OSS), (JACK, JACK)
and we would disable or blacklist JACK in PortAudio.
nothing else except status infos, since everything is set by the jack server. All mix channels are exposed to jack with proper names.
-- You received this bug notification because you are a member of Mixxx Development Team, which is subscribed to Mixxx. https://bugs.launchpad.net/bugs/1172299
Title: Jack Audio Connection Kit Implementation Does not Follow Normal Behaviour
To manage notifications about this bug go to: https://bugs.launchpad.net/mixxx/+bug/1172299/+subscriptions
mixxxbot
commented
2 years ago Commented by: Michael-Z-Freeman Date: 2013-04-27T10:40:02Z
I don't feel that either of you have properly read my last posts. Did you look at my GUI mock ups ? I am a user of Mixxx and feel that I have put together a useful contribution that will improve Mixxx usability AND while KEEPING Portaudio.
mixxxbot
commented
2 years ago Commented by: bkgood Date: 2013-04-27T23:43:14Z
Attaching my name to this to remind myself to have a look at it, feel free (whoever) to steal it.
I'm not totally convinced that this can't be accomplished with PortAudio (although comments do seem to suggest otherwise, and my memory is surely shoddy), I intend to look into it.
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2013-04-28T08:23:46Z
Hi Bill, I am happy you (probably) picked it up.
I am still in favor a native SoundDeviceJack, but of cause a slick Portaudio solution would be an option. It might be possible to expose our channels to PortAudio like PaJack_SetClientName and leave them unconnected, but this introduces a complete new philosophy to Portaudio and require heavily patching inside Portaudio and Mixxx.
Here some other arguments against:
On all Plattforms there are propper sound APIs without Jack. Jack is a wrapper like Protaudio but aims to to be very flexible in plugging together a sound setup and low latency. So our case, wrapping Jack by Portaudio for a universal API is somehow wired. You probably loose all key benefits of Jack. It is something like double wrapped. Don't know what latency result this produces. At least I see a copy from Jack buffer to the Portaudio ring buffer in the Portaudio pa_jack.c. I think that is used to adapted th jack buffer size form the Jack settings to the Latency selected in Mixxx. A SoundDeviceJack would be simply run directly on the Jack buffer for synced Latency among all Jack clients.
IMHO only suitable way to use Jack in a way it is intended is to write a SoundDeviceJack.
Kind regards,
Daniel
mixxxbot
commented
2 years ago Commented by: Michael-Z-Freeman Date: 2013-04-28T12:22:33Z
Appreciate you comments, but, respectfully, I don't think you’re right about Jack being a "wrapper". I think you’re thinking of Jack as a traditional sound output API. It is very different from that, and could bring a lot of power to Mixxx if the devs decided to go that way. For example looks at JackEQ - http://djcj.org/jackeq/ - for something that Mixxx could be doing, although I realise that may not be in the goals that Mixxx has. As a user of Jack who (I think) has understood its revolutionary nature, I probably need to put something in a document for the Mixxx team to help clear up some of the confusion (?) here. Would that be a Blueprint or proposal of some kind ?
mixxxbot
commented
2 years ago Commented by: rryan Date: 2013-04-28T12:57:11Z
Hey DJ_Barney
Sorry if it seems like were ignoring your input :). A lot of us know JACK quite well and do appreciate that it's a great paradigm to deal with audio routing. I have used the JACK API a lot in other projects. We're just trying to figure out what makes the most sense for mixxx architecturally and project-wise.
Unfortunately we must figure out a nice way to deal with audio routing for all of our users on windows mac and Linux. So whatever solution we come up with will basically require cramming two different paradigms into one backend and one UI. (I know JACK is cross platform but I have never heard from a single user on windows or Mac that use it). Mixxx has to be "full stack" so that anyone can just install it and get going with nothing else.
I have to agree with you Daniel that portaudio is not likely to want to put
in the effort. That said, before we go and do this work we should start a
discussion with Ross about it. I don't want to do it only to learn they
would have been happy to accommodate us. Code is a liability and I am just
trying to minimize our SLOC count because that is the easiest way to have
fewer bugs ;).
For example, pulseaudio support in portaudio is a much better place for it
than to make a pulseaudio sound device in Mixxx.
On Apr 28, 2013 8:30 AM, "DJ_Barney" <email address hidden> wrote:Appreciate you comments, but, respectfully, I don't think you’re right about Jack being a "wrapper". I think you’re thinking of Jack as a traditional sound output API. It is very different from that, and could bring a lot of power to Mixxx if the devs decided to go that way. For example looks at JackEQ - http://djcj.org/jackeq/ - for something that Mixxx could be doing, although I realise that may not be in the goals that Mixxx has. As a user of Jack who (I think) has understood its revolutionary nature, I probably need to put something in a document for the Mixxx team to help clear up some of the confusion (?) here. Would that be a Blueprint or proposal of some kind ?
-- You received this bug notification because you are a member of Mixxx Development Team, which is subscribed to Mixxx. https://bugs.launchpad.net/bugs/1172299
Title: Jack Audio Connection Kit Implementation Does not Follow Normal Behaviour
To manage notifications about this bug go to: https://bugs.launchpad.net/mixxx/+bug/1172299/+subscriptions
mixxxbot
commented
2 years ago Commented by: Michael-Z-Freeman Date: 2013-04-28T20:46:00Z
It's OK. I don't think I was explaining my concept particularly clearly to begin with :)
I'm so glad that you have perceived the paradigm shifting nature of Jack ! As you can probably tell I start drooling over the possibilities every time I start getting ideas of what Jack could bring to Mixxx; Jack audio inputs into each deck ? Send and Receive FX routing (as many professional hardware Mixers have) out to Jack-rack; no need to worry about writing a custom FX part ot Mixxx any more (?) - just hand that out to applications specially written for that purpose. Jack MIDI inputs allowing multiple control surfaces to control Mixxx at once ? Anyway, I could go on ...... I understand that its SO important to maintain focus for a project such as this. If Mixxx is easier to use and port to as many different OS'es as possible, but Jack support suffers, then so be it. But I think its worth defining what Jack could potentially bring to Mixxx, and how that could allow Mixxx to fit into Jack Audio set ups, as other solutions may present themselves in the future (Ross may be willing to make the changes that will help Mixxx, design goals may change, etc, etc). I intend to do that in a Blueprint. If there are any other brainstorming Jack users out there then I suggest you put in a Blueprint as well.
mixxxbot
commented
2 years ago Commented by: ywwg Date: 2013-04-30T16:09:15Z
Hi DJ_Barney,
A lot of what you want to do is already possible in Mixxx, and I do it. I use the individual deck outputs in Mixxx to forward the audio to a set of jack-racks that handle effects and crossfading. (There's not even a need to bring the altered output back in to mixxx). Even though Mixxx connects jack devices itself, I have a script that disconnects the devices and then reconnects them to my racks. You can still use qjackctl! Mixxx already supports multiple control surfaces so we don't need JACK for that. And with the passthrough code that we'll be checking in shortly (to trunk), you can have external inputs from other programs.
Yes, the naming is a little inconvenient, but the actual functionality you are looking for is already there.
mixxxbot
commented
2 years ago Commented by: Michael-Z-Freeman Date: 2013-04-30T17:12:26Z
Hello. I disagree. Its great that Mixxx has these functions but the entire point of Jack is that it provides a common standard for doing these things. Plus it would make perfect sense having an FX return bus. Why do you think professional hardware mixers do it this way ? Its so there are a common set of easy to use controls ... not Jack apps spread all over the place that are difficult to switch to in the middle of live performances. Anyway, I'll stop there before this bee in my bonnet starts buzzing a little too much ! I'm gonna lay this all down in a blueprint.
mixxxbot
commented
2 years ago mixxxbot
commented
2 years ago Commented by: rryan Date: 2016-01-01T03:03:24Z
Sure, though we're swimming in these "someday" bugs and I'm trying to close as many of them as I can. :)
As I said 2 years ago, code is a liability and I can't support a direct dependence on JACK as a solution to this bug from a code and project maintenance perspective. There would have to be an extremely compelling product use case for that to make sense.
If we can work with PortAudio to improve their JACK-specific customization that would be a great solution to this bug.
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2016-01-01T10:49:37Z
I am afraid the PortAudio interface will never suit for this (Or needs mayor re factoring).
I think to a solution where Mixxx exposes all streams to Jack and get reported back if the stream is used or not. In case it is used, Mixxx should start processing automatically.
A solution using the Jack API should be very straight forward.
mixxxbot
commented
2 years ago Commented by: santeri-toikka Date: 2016-01-07T19:16:00Z
I noticed, that starting up mixxx shuts down my jackdbus server. I'll try to fish from logs why this happens. I'm on Arch and building from master (75de8d6 currently).
mixxxbot
commented
2 years ago Commented by: santeri-toikka Date: 2016-01-07T20:12:31Z Attachments: [Jackdbus log](https://bugs.launchpad.net/mixxx/+bug/1172299/+attachment/4545848/+files/Jackdbus log)
There is definitely something wrong with naming.
Jack aborts or dies when mixxx/portaudio tries to register a new client with really suspicious name.
I have attached the jackdbus log where the funny naming is visible.
mixxxbot
commented
2 years ago Commented by: santeri-toikka Date: 2016-01-07T20:29:41Z Attachments: [mixxx log](https://bugs.launchpad.net/mixxx/+bug/1172299/+attachment/4545856/+files/mixxx log)
Here is edited mixxx console output about the previous error.
I'm able to use jack only after these steps:
It seems like the hw device list is populated only on startup, which leads to this extra juggling with jack.
The next restart of mixxx leads to same problem. I am guessing that part of the problem is in restoring previous state from saved configuration.
There is also no need to use alsa layer for jack connectivity, but this could be result of my own configuration and default alsa device setting rather than portaudio behaviour. I have alsa_jack_sink of type jack as a default pcm target in my asound config.
mixxxbot
commented
2 years ago Commented by: uexplorer Date: 2016-02-03T10:29:18Z
Every time, when the output connections are altered, the names for jack output channels are incremented. Is this an PortAudio behavior?
When I start and configure a clean mixxx with jack (and this is the only audio-setup that I'll use) with Master Mix enabled, the output jack channels are named out_1 and out_2. If I add a additionally jack-audio-device and connect to a output, previously out_1 and out_2 will now be out_3 and out_4, the additional outs will by out_5 and out_6 and so on.
I think this is unfavourable... I'm very glad, if this can be fixed! Thanks for your wok on mixxx!
Reported by: Michael-Z-Freeman Date: 2013-04-24T14:23:34Z Status: Confirmed Importance: Wishlist Launchpad Issue: lp1172299 Tags: jack Attachments: mixxx_jack_output_preferences.png, mixxx_jack_input_preferences.png, [Jackdbus log](https://bugs.launchpad.net/bugs/1172299/+attachment/4545848/+files/Jackdbus log), [mixxx log](https://bugs.launchpad.net/bugs/1172299/+attachment/4545856/+files/mixxx log)
There are some issues with Jack Audio Connection Kit behaviour. It does not follow standard Jack behaviour ...
The Mixxx preferences dialog for Jack is not set up in the usual way. Other apps just connect to the Jack server and present their connections there without presenting them in their own GUI. This is the usual Jack behaviour. Jack connections are best handled by software such as QJackCtl. There is no need to show the drop down lists when Jack is selected.
The Jack connection names are not correct ...
A. They are numberd from 0 (zero) when other Jack apps have them numbered from 1 (one).
B. They don't have proper names. Hydrogen names all its outputs by instrument name or just "Out_L" and "Out_R" if its not setup per instrument. Ardour has proper names like "auditioner/out 1", "auditioner/out 2". Same for "click" and it gives the names of the various tracks if they have been named by the user. The outputs and inputs should be presented to Jack server with the names as they are given on the left of the drop down boxes in the Mixxx Jack preferences GUI.
Examples of proper Jack behaviour can be found in Hydrogen and Ardour, and other Jack software and their relationship to QJackCtl.
I looked for a "best practices" document that might describe how best to implement Jack in an application. I'll comment here if I find one. However it is the users of Jack that know how it "should" work. This really only becomes apparent after fully familiarising oneself with Jack.