Re: [pulseaudio-discuss] rygel mediaserver

2011-04-16 Thread Gunnar Aastrand Grimnes 

Solved! My WDTV now plays the live-audio stream with no problem!

For the record:

HTTP HEAD *is* broken in 0.9.22, but is fixed in git master in commit 
f8aceafb1321fb2254f6cafea25c14f07a78ad49


This was ticket http://pulseaudio.org/ticket/781 with attached patch.

I fixed my debian system by applying that patch to the 0.9.22 sources 
and recompiling.


coling said he'll apply it for 0.9.23 as well.

Cheers!

- Gunnar

On 13/04/11 20:11, Gunnar Aastrand Grimnes wrote:

A tiny bit more detail - I tried running wireshark while trying to play
the stream, the WDTV asks for the stream:

HEAD /listen/source/alsa_output.pci-_00_06.1.analog-stereo.monitor
HTTP/1.0\r\n
[...]

And pulseaudio responds:

HTTP/1.0 500 Internal Server Error\n

:)

The body returned contains no more useful info.

Testing the same with curl give the same result:

curl -I
http://localhost:4714/listen/source/alsa_input.pci-_00_06.1.analog-stereo

HTTP/1.0 500 Internal Server Error
Connection: close
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Expires: 0
Server: pulseaudio/0.9.22

Actually HTTP GET'ing the stream with curl works fine.

I made a ticket: http://pulseaudio.org/ticket/933

Cheers!

- Gunnar

On 12/04/11 21:50, Gunnar Aastrand Grimnes wrote:

I think you have to load module-protocol-http as well (not sure I've got
the name totally correct).


That's the one I meant when I said I have also enabled the http-tcp
module, - it's called module-http-protocol-tcp



I tried it with my PS3 but never got very far (it defo did try to talk
to the http module tho')

If you get it working with your WDTV box just by loading http protocol,
please report back and I'll tweak paprefs.


No such luck. Running pa in a console it says:


I: socket-server.c: TCP connection accepted by tcpwrap.
I: client.c: Created 12 HTTP client (TCP/IP client from
192.168.178.99:41994)
I: client.c: Freed 12 HTTP client (TCP/IP client from
192.168.178.99:41994)

immediately, and the WDTV says unable to play the selected file.

With my LG HB405SU there is on such message, but rygel says:

** (rygel:10171): WARNING **: rygel-http-request.vala:91: Invalid seek
request

When I try to play the stream.

Cheers,

- Gunnar
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] RFC: Filter module loader

2011-04-16 Thread Jason Newton 

On 04/15/2011 08:28 PM, Tanu Kaskinen wrote:

On Fri, 2011-04-15 at 23:21 +0200, Maarten Bosmans wrote:

Do the developers of those applications feel the same? Perhaps this is
a right time to step back and think about what we want to achieve. I'd
say that some sort of client-side access to volume ramping
(fade-in/fade-out) is appropriate. But effects like equalizer is
probably better off in a gstreamer pipeline.

Doing effects in Pulseaudio removes the need to implement equalizer
support in each and every music player. With better filter support it
should also be easy to configure per-output eq settings. If the user
uses both speakers and headphones, the same settings very likely aren't
ideal for both outputs. Clients shouldn't care about the current
routing, so this is another reason why Pulseaudio is the right place for
user equalizers.

Also doing it in pulseaudio prevents some applications from slipping 
through without the desired effects being applied, such as flash.  This 
was a primary motivator for putting it in pulseaudio when I first wrote it.

I'm sorry for sounding perhaps a bit grumpy, but I am a bit hesitant.
This is really something that should be planned carefully. PulseAudio
can't be everything for everybody. That said, it is perfectly possible
that I miss some important usage scenario's, especially you seem to be
working on embedded stuff, with other demands on pulse.
Maybe not for every filter but just as the equalizer is easily 
justified, other plugins as well (ie normalized volume, preventing 
commercials from blasting your eardrums) - especially considering 
internet tv (hulu/youtube etc) will not be cooperative with any level 
above pa.  dependancy on floating point keeps it above kernel and 
potentially out of alsa (not sure here, but also alsa limits reusability 
assuming pa can run on multiple platforms).

Embedded systems (or at least phones) require very flexible filter
setups at the level where Pulseaudio is operating. There are many
filters that need to be dynamically enabled and disabled at runtime.

You may be right in that this sounds like reimplementing gstreamer,
though. At least I have had some ideas about reimplementing the whole
audio processing pipeline (volumes, mixing, resampling, filters) as
abstract elements like in gstreamer... The reason being mostly that then
rewinds could maybe be done in some generic (i.e. understandable) way
instead of the current approach that seems like a mess (on the surface
at least - I haven't *really* tried to grok it).

I believe I pitched gstreamer to Lennart before feeling the distaste of 
reimplementation and he said this was a bad idea because of all the 
threading/latency stuffs going on there.


One problem I faced in developing the equalizer module is the latency at 
which the filter runs at (=required # of samples before an output is 
defined) did not run well with rewinds and pa autolatency-adjustement 
jazz.  Because of this, and what I was told about the method of which 
I'm attenuating frequency responses from the speex codec author, I will 
be, at some point hopefully in the somewhat near future, switching to an 
IIR filter which will have 1 (or some such low #) sample latency 
hopefully so I can so I don't kludge up the rest of the pipeline.  In 
doing so I will unfortunately make the filtering code more complex and I 
will lose the resolution of the attenuation adjustment.  It will be 
closer over all to more typically equalizers seen in the wild with 8 or 
so fixed bands.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] review+pull-request: Passthrough support

2011-04-16 Thread Dark Shadow 
On Thu, Apr 14, 2011 at 5:49 AM, Arun Raghavan
arun.ragha...@collabora.co.uk wrote:
 On Wed, 2011-04-13 at 18:23 +0530, Arun Raghavan wrote:
 [...]
 The changes needed to actually use this in GStreamer are also done, but
 not upstream yet. I need to do some rebasing to make this stuff good to
 push out, so details on this in a following mail.

 Okay, this is also pushed and good to test. I'll be pushing this out to
 master after the next round of gst* releases (which should happen in the
 next couple of weeks or so). For now, you'll need:

 * gstreamer from git master
 * gst-plugins-base from:
 http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough
 * gst-plugins-good from:
 http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough
 * gst-plugins-bad, gst-plugins-ugly, gst-ffmpeg built against the above
 would probably also be needed (for non-passthrough playback)

 With all but the top-most commit to gst-plugins-good, pulsesink will be
 plugged in passthrough mode when the sink supports the format of the
 input.

 The top-most commit on gst-plugins-good introduces a new pulsesinkbin
 element, which automatically reconfigures based on what formats are
 available on the sink we're connected to. So if you're playing AC3 in
 passthrough mode over S/PDIF and switch to analog out, it'll
 transparently plug in a decoder, and if you switch back to digital out,
 the decoder will be removed and passthrough mode will be enabled again.

 pulsesinkbin will be autoplugged if your app (or gst-launch) is using
 playbin2, but most applications totem/rhythmbox/... override the
 playbin2 audio sink, so there's some work pending before this just works
 with players.

 I'm happy to help if anyone runs into problems while testing.

 Cheers,
 Arun

 p.s.: for those of you who want to test but don't have a
 gstreamer-from-git setup already, jhbuild[1] or gst-uninstalled[2]
 should be useful.


I have been using this branch for awhile (since the first day XBMC
could use it to passthrough DTS-HD) and will it worked for most that
time yesterday I updated to the most recent git pull and now
pulseaudio doesn't even see my Nvidia HDMI at all anymore. It doesn't
show as a possible sink.

This is on a XBMC-Live dedicated HTPC that nothing else has changed in
recent time.

I can still use HDMI by using straight Alsa so nothing happened to it.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Is this a Pulseaudio bug or a Vala bug? (v2)

2011-04-16 Thread Alexander Kurtz 
Hi,

I think I got it: With the attached patch I am successfully able to use
channel maps in vala in my program. Here are the details:

1. Remove the has_destroy_function=false attribute. It was only
necessary because of a bug in vala which is fixed in 0.12. [1]

2. Add sizes to all fixed-size arrays to make vala recognize them as
such. Using symbolic constants for this is not yet supported. [2]

3. CardInfo struct: Move the brackets in the list of available profiles
to the type to make it clear that this is a dynamically-sized array. [3]

Please merge this into master if you have no objections.

Best regards

Alexander Kurtz

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622773
[2] https://bugzilla.gnome.org/show_bug.cgi?id=647788
[3] 
http://0pointer.de/lennart/projects/pulseaudio/doxygen/structpa__card__info.html
diff -Naur a/libpulse.vapi b/libpulse.vapi
--- a/libpulse.vapi	2011-04-05 12:24:12.0 +0200
+++ b/libpulse.vapi	2011-04-14 20:31:28.876372889 +0200
@@ -243,7 +243,8 @@
 [CCode (cname=pa_cvolume)]
 public struct CVolume {
 public uint8 channels;
-public Volume values[];
+// TODO: Replace array length with CHANNELS_MAX once vala's bug #647788 is fixed
+public Volume values[32];
 
 [CCode (cname=PA_SW_CVOLUME_SNPRINT_DB_MAX)]
 public static const size_t SW_SNPRINT_DB_MAX;
@@ -373,10 +374,11 @@
 public unowned CVolume? dec(Volume minus = 1);
 }
 
-[CCode (cname=pa_channel_map,has_destroy_function=false)]
+[CCode (cname=pa_channel_map)]
 public struct ChannelMap {
 public uint8 channels;
-public ChannelPosition map[];
+// TODO: Replace array length with CHANNELS_MAX once vala's bug #647788 is fixed
+public ChannelPosition map[32];
 
 [CCode (cname=PA_CHANNEL_MAP_SNPRINT_MAX)]
 public static const size_t SNPRINT_MAX;
@@ -1350,7 +1352,7 @@
 public uint32 owner_module;
 public string driver;
 public uint32 n_profiles;
-public CardProfileInfo profiles[];
+public CardProfileInfo[] profiles;
 public CardProfileInfo *active_profile;
 public Proplist proplist;
 }


signature.asc
Description: This is a digitally signed message part
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] review+pull-request: Passthrough support

2011-04-16 Thread Dark Shadow 
On Sat, Apr 16, 2011 at 9:39 AM, Dark Shadow shadowofdarkn...@gmail.com wrote:
 On Thu, Apr 14, 2011 at 5:49 AM, Arun Raghavan
 arun.ragha...@collabora.co.uk wrote:
 On Wed, 2011-04-13 at 18:23 +0530, Arun Raghavan wrote:
 [...]
 The changes needed to actually use this in GStreamer are also done, but
 not upstream yet. I need to do some rebasing to make this stuff good to
 push out, so details on this in a following mail.

 Okay, this is also pushed and good to test. I'll be pushing this out to
 master after the next round of gst* releases (which should happen in the
 next couple of weeks or so). For now, you'll need:

 * gstreamer from git master
 * gst-plugins-base from:
 http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough
 * gst-plugins-good from:
 http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough
 * gst-plugins-bad, gst-plugins-ugly, gst-ffmpeg built against the above
 would probably also be needed (for non-passthrough playback)

 With all but the top-most commit to gst-plugins-good, pulsesink will be
 plugged in passthrough mode when the sink supports the format of the
 input.

 The top-most commit on gst-plugins-good introduces a new pulsesinkbin
 element, which automatically reconfigures based on what formats are
 available on the sink we're connected to. So if you're playing AC3 in
 passthrough mode over S/PDIF and switch to analog out, it'll
 transparently plug in a decoder, and if you switch back to digital out,
 the decoder will be removed and passthrough mode will be enabled again.

 pulsesinkbin will be autoplugged if your app (or gst-launch) is using
 playbin2, but most applications totem/rhythmbox/... override the
 playbin2 audio sink, so there's some work pending before this just works
 with players.

 I'm happy to help if anyone runs into problems while testing.

 Cheers,
 Arun

 p.s.: for those of you who want to test but don't have a
 gstreamer-from-git setup already, jhbuild[1] or gst-uninstalled[2]
 should be useful.


 I have been using this branch for awhile (since the first day XBMC
 could use it to passthrough DTS-HD) and will it worked for most that
 time yesterday I updated to the most recent git pull and now
 pulseaudio doesn't even see my Nvidia HDMI at all anymore. It doesn't
 show as a possible sink.

 This is on a XBMC-Live dedicated HTPC that nothing else has changed in
 recent time.

 I can still use HDMI by using straight Alsa so nothing happened to it.


Don't worry, it must of been a random problem after rolling back to
old versions of your passthrough branch then moving up one commit at
at time to try and track the breakage I made it back to the newest
with it working again.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss