Jack output fundamentally broken

Bug #1499987 reported by Gordonjcp
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gmusicbrowser (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Every time a track starts, gmusicbrowser connects its jack output ports to the system output. This is pretty much never what you want, because it means that if you route the output from gmusicbrowser through jack you need to reconnect it to whatever destination you really wanted at the end of every song.

In addition, the output is severely clipped.

Revision history for this message
Quentin Sculo (squentin) wrote :

I must admit I don't know much about jackd. From my simple test playing on alsa (jackd -d alsa), it seems to work fine. So it'd be nice if you could explain how I could see the problem for myself.

I _think_ the problem is that gmb set the gstreamer the playbin to the 'null' state rather than the 'ready' state when stopping. In that case it would be easy to fix, though I don't want it to keep resources open indefinitely when not playing, so maybe after 1 minute it should set the state to 'null'.
If that is the problem, it should not happen when the gapless option is turned on and you are not playing in a weighted random mode, as in that case the state is never set to 'null' between track.

About clipping, the only possible reason I can think of is the replaygain or equalizer options, you can turn them off near the bottom of the audio tab in the settings dialog.

Revision history for this message
Gordonjcp (gordonjcp) wrote :

I'll try that - perhaps gapless playback will solve the problem.

An app should never disconnect from jack unless it's told to (possibly by exiting). If it's disconnecting because the output is set to null, then doing that after a minute will cause the problem to occur if you pause the music for more than a minute - what happens when you restart playing?

Revision history for this message
Gordonjcp (gordonjcp) wrote :

Just tried it - it doesn't "hop" between songs but it does if you select a new song.

Revision history for this message
Quentin Sculo (squentin) wrote :

Bad news, using the 'ready' state instead of 'null' doesn't solve your problem. When playing with the gapless option, the state is kept to 'playing' so that's why it worked.

After looking a bit, it seems that's how most players work (as opposed to 'pro'/creation audio software), the work-around is to use patchbay so that your routes are restored as needed when the player plays a song.

Always keeping the gstreamer jacksink element in the 'playing' state, although possible, would be too complicated, and still the routes wouldn't survive the shutdown of gmb (unlike with patchbay).

So I'll close this as WON'T FIX ("invalid"). Though if someone find an example of a player that does this, mention it here or by email, and I will take a look to see if it can be done in gmb too.

Also, looking at the doc for the jack gstreamer element (http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-jackaudiosink.html) there is a potentially interesting property: port-pattern,
I couldn't test it as it is new in gstreamer 1.6, but maybe it could help, it is a text pattern that is used to choose which port it should connect to. I can easily add this option in gmb if it could be useful, let me know.

Changed in gmusicbrowser (Ubuntu):
status: New → Invalid
Revision history for this message
Quentin Sculo (squentin) wrote :

Also, I forgot to mention another work-around: use the pulse-audio output and use a pulse-audio plugin to connect to JACK : http://www.penguinproducer.com/Blog/2011/09/using-jack-with-different-non-jack-programs/

Revision history for this message
Gordonjcp (gordonjcp) wrote :

Pulseaudio and jack don't seem to play nicely together, because it gives horrible crunching distortion. I suspect someone somewhere is making a faulty assumption about scaling.

The patchbay thing works well enough to solve the immediate issue.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.