Bug 76468 - GStreamer output does not work
Summary: GStreamer output does not work
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: 2.0
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Scott Wheeler
Depends on:
Reported: 2004-03-01 01:12 UTC by Evan Dandrea
Modified: 2005-06-02 19:07 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:

add support for KGST_SINK env var (2.49 KB, patch)
2004-08-26 08:50 UTC, Justin Mason

Note You need to log in before you can comment on or make changes to this bug.
Description Evan Dandrea 2004-03-01 01:12:08 UTC
Version:           2.0 (using KDE KDE 3.2.0)
Installed from:    Debian testing/unstable Packages
OS:          Linux

Using "Output to GStreamer..." with ESD.  Killing ESD solves the problem.

INFO (12348: 0) Initializing GStreamer Core Library version 0.6.4
INFO (12348: 0) CPU features: (00000000) MMX SSE
INFO (12348: 0) registry: loaded user_registry in 0.000481 seconds
INFO (12348: 0) registry: loaded global_registry in 0.218711 seconds

(process:12348): GStreamer-WARNING **: push on peer audioQueue:sink of pad src_0:src but peer is not active

The above message repeats until the song is stopped.  JuK acts like it is playing the song, the track position changes, but it does not produce any audio.  I don't believe this is necessarily a GStreamer bug because Rhythmbox has no trouble at all playing any of the same songs.

I would assume JuK -> GStreamer -> ESD is ok, I browsed around the cvs tree a little and came up empty looking for documentation explaining otherwise, but I apologize if I missed something.
Comment 1 Scott Wheeler 2004-03-01 01:30:02 UTC
It's currently hardcoded in the GStreamer bindings to use OSS output.  What you're seeing is that it's unable to open the sound device because ESD is running.  You might try running JuK with "esddsp juk --nofork" to see if it's able to reroute it.

At some point it's likely that there will be a GStreamer KControl module that ships with the KDE bindings, but since that currently doesn't exist there's not a way to fix this inside of JuK.
Comment 2 Justin Mason 2004-06-29 01:08:17 UTC
I'm getting this too; the esddsp / artsdsp trick (I'm hoping to use artsd) doesn't work, AFAICS.  in other words, JuK hogs /dev/dsp.  Since artsd expects to "own" that device, it can't coexist with JuK in any reliable way.
is there *any* way to override the sink JuK will use?  even hacking a config file, or rebuilding from source, is fine by me.

Given that 

   gst-launch filesrc location=test.mp3 \! spider \! osssink

fails to work, but

   gst-launch filesrc location=test.mp3 \! spider \! artsdsink

works fine, that's all I need.
Comment 3 Scott Wheeler 2004-06-29 01:15:29 UTC
On Tuesday 29 June 2004 1:08, Justin Mason wrote:
> is there *any* way to override the sink JuK will use?

This was hardcoded into the GStreamer bindings -- that will be changed in the 
next release.

Just do s/osssink/artssink/ in gst/kde/gstplay.cpp

Comment 4 Justin Mason 2004-08-26 08:50:50 UTC
Created attachment 7294 [details]
add support for KGST_SINK env var

fwiw -- this patch to kgst adds support for a KGST_SINK environment variable,
so that 'osssink' can be overridden if desired.  (it works with JuK too ;)
Comment 5 Justin Mason 2004-11-06 04:13:36 UTC
I've just opened bug 92786 (on the gst libraries in particular), with that patch, hoping to get it applied.
Comment 6 Justin Mason 2005-06-02 19:07:55 UTC
just an update --

I currently have this worked around.  here's how.

1. set up esd on the machine.  with ALSA installed (modern kernels) that means running "aoss esd".

2. set up KDE to run artsd with ESD output.

3. set up JuK to output via artsd.

in other words, the sound output goes via 3 layers of indirection: artsd -> esd -> ALSA dmix -> hardware.  but hey, it plays, and other apps can access the hardware while juk is running so I'm happy...