Re: [pulseaudio-discuss] Support for audio envelopes
On Fri, 2012-07-20 at 17:32 -0300, Flavio Ceolin wrote: Tanu Kaskinen ta...@iki.fi writes: There were problems with the code. I don't remember what exactly was broken, though. But at least I didn't like the concurrency handling: I really dislike doing inter-thread communication by using shared variables. Instead, message passing should be used, in my opinion. I'll investigate how to solve it. Btw, do you think it's better start from the scratch or it's ok start from this code ? I really don't know. I'm not familiar enough with the code to know how much of it needs rewriting. I know that Jaska Uimonen has been working with volume envelopes too, and asked him yesterday about the status. He said he will post the code to the mailing list on Monday. I haven't seen the code, but if it's good, then it might be a good starting point too (Jaska said that it's lacking multichannel support, so work will be needed). 2) How an application should use this code, AFAIK this code is not being exported. What's your use case? If we are talking about sink volume ramping, I don't see the need for a client interface at all, because it should be done automatically by the server. Basically I want to set an envelope which apply a filter changing the sound balance and/or the volume, it's easier demonstrating an idea of an envelope: But what's the use case (user-visible feature) that you're interested in? My answer to the how an application should use this code depends on the use case. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Problems in alsa device detection with M-Audio Fast Track Ultra
On Fri, 2012-07-20 at 19:30 +0200, Robert M. Albrecht wrote: Hi, I'm using a M-Audio Fast Track Ultra on Fedora 17. And you're having problems in alsa device detection, according to the subject. A pulseaudio log of the pulseaudio startup would be useful: https://wiki.ubuntu.com/PulseAudio/Log Pulseaudio seems not to know S24_3LE for daemon.conf ? default-sample-format= The default sampling format. Specify one of u8, s16le, s16be, s24le, s24be, s24-32le, s24-32be, s32le, s32be float32le, float32be, ulaw, alaw. Depending on the endianess of the CPU the formats s16ne, s16re, s24ne, s24re, s24-32ne, s24-32re, s32ne, s32re, float32ne, float32re I tried several sample-formats, but none of them seem to work. Did you try s24le? That's the one that corresponds to alsa's S24_3LE. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] SDP LF vs. CRLF
On Thu, 2012-07-19 at 00:41 +0200, Christian K. wrote: Hello, I'm currently trying to connect PulseAudio with VLC using RTP. The SDP sent by VLC is not parsed by PulseAudio, the error is invalid header. I discovered that PulseAudio seems to expect that the SDP descriptor contains just LF i.e. \n line breaks whereas VLC is sending CRLF line breaks as it is also specifiied in the RFC [1]. Can somebody confirm this inconsistency? Yes, src/modules/rtp/sdp.c prints Failed to parse SDP data: invalid header. if the SDP data doesn't start with PA_SDP_HEADER, which is defined as v=0\n. There may be assumptions about the line terminator always being \n in pa_sdp_parse() also later in the function, so fixing just that one check may not be enough. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] SDP LF vs. CRLF
Hello, Le jeudi 19 juillet 2012 01:41:52 Christian K., vous avez écrit : I'm currently trying to connect PulseAudio with VLC using RTP. The SDP sent by VLC is not parsed by PulseAudio, the error is invalid header. I discovered that PulseAudio seems to expect that the SDP descriptor contains just LF i.e. \n line breaks whereas VLC is sending CRLF line breaks as it is also specifiied in the RFC [1]. To be precise, the RFC requires writing CRLF and reading both CRLF and LF. Jon Postel principle applies. Clearly, there is a PulseAudio bug. Note though that: - PulseAudio also fails to use the standard SAP multicast group addresses, so it will not interoperate with VLC out of the box. - In the VLC-PulseAudio direction, VLC must be configured to transcode to 's16b', as PulseAudio is not able to decode non-linear audio commonly found in RTP. Regards, -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] pavucontrol: Show available status
Having an object model that properly links ports to both cards and
sinks/sources would very likely be useful in the future also. Actually,
poljar has had the same problem with his latency offset feature. I don't
know if he already has a solution that you could re-use...
I added a port class to the cardwidget. I don't know if we need the
proplists or the profile list so suggestions are welcome.
Note: this does nothing visible for now.
Patch attached.
From 8c36669e9883a96ba77353f62c7539ccf6419ab7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?poljar=20(Damir=20Jeli=C4=87)?= poljari...@gmail.com
Date: Sat, 21 Jul 2012 13:43:54 +0200
Subject: [PATCH] cardwidget: Add a port class
The cardwidget should cache all the relevant data for the ports.
This change introduces a new port class which holds the port info for
the card.
---
src/cardwidget.h | 11 +++
src/mainwindow.cc | 18 ++
2 files changed, 29 insertions(+)
diff --git a/src/cardwidget.h b/src/cardwidget.h
index 3837d5b..7c63681 100644
--- a/src/cardwidget.h
+++ b/src/cardwidget.h
@@ -23,6 +23,16 @@
#include pavucontrol.h
+class PortInfo {
+public:
+ Glib::ustring name;
+ Glib::ustring description;
+ uint32_t priority;
+ int available;
+ int direction;
+ int64_t latency_offset;
+};
+
class CardWidget : public Gtk::VBox {
public:
CardWidget(BaseObjectType* cobject, const Glib::RefPtrGtk::Builder x);
@@ -36,6 +46,7 @@ public:
bool updating;
std::vector std::pairGlib::ustring,Glib::ustring profiles;
+std::mapGlib::ustring, PortInfo ports;
Glib::ustring activeProfile;
bool hasSinks;
bool hasSources;
diff --git a/src/mainwindow.cc b/src/mainwindow.cc
index dc84682..6a4094c 100644
--- a/src/mainwindow.cc
+++ b/src/mainwindow.cc
@@ -290,6 +290,24 @@ void MainWindow::updateCard(const pa_card_info info) {
w-activeProfile = info.active_profile ? info.active_profile-name : ;
+if (pa_context_get_server_protocol_version(get_context()) = 26) {
+for (uint32_t i = 0; i info.n_ports; ++i) {
+PortInfo p;
+
+p.name = info.ports[i]-name;
+p.description = info.ports[i]-description;
+p.priority = info.ports[i]-priority;
+p.available = info.ports[i]-available;
+p.direction = info.ports[i]-direction;
+
+if (pa_context_get_server_protocol_version(get_context()) = 27)
+p.latency_offset = info.ports[i]-latency_offset;
+else p.latency_offset = 0;
+
+w-ports[p.name] = p;
+}
+}
+
w-updating = false;
w-prepareMenu();
--
1.7.11.2
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] AMD chipset HDMI and SPDIF outputs lack surround sound modes
Hello, I'm running Ubuntu 12.04 with two computers both with AMD video chipsets. Both of the sinks I need to output sound on have no mode setting in Gnome sound config. The analog outputs show surround options available, but S/PDIF and HDMI options only offer stereo output. Is there some way in which I can contribute to enhance Pulseaudio so that future versions will have this corrected? On a separate topic, is there a way to force it to output with more channels until a patch is applied? I've tried messing around with pacmd and can't figure out how to set the channels. Does this need to be done through editing one of the config files? Thanks! Yfrwlf ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ALSA sink stuck at 48kHz
On Jul 20, 2012, at 1:53 PM, Pierre-Louis Bossart wrote: Weird. Can you try setting both frequencies to 44100 and see what happens? I can't think of any reason why this behavior happens. If I set the default and alternate sample rates to 44100 in daemon.conf it doesn't display any error message but opens the DAC at 48kHz. And I didn't specified any argument to the alsa-sink module. -- Louis Opter ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] Immediate underrun with PulseAudio ALSA plugin when PA and ALSA buffer sizes differ
2012-7-19 上午6:14 於 Matthew Gregan kine...@flim.org 寫道： No, it's just a random value for media playback. In an older version of the audio backend we're using in Firefox (which was push rather than pull based), we used 500ms and hadn't run into this problem in a way that was obvious to users (i.e. causing broken playback). I chose a lower latency for media playback in the new backend in an attempt to flush out bugs before we introduce features that demand low latency (such as WebRTC). Could you clarify what versions of PulseAudio and alsa-plugins you're using? The latest improvement to this handling was done less than a year ago and might require the latest versions of these components. I'm using Fedora 17, which has alsa-plugins-pulseaudio-1.0.25-3.fc17 and pulseaudio-1.1-9.fc17. This was originally discovered by users running ALSA 1.0.25 on various distros (Ubuntu 12.04 LTS and Arch). Two of them happened to have a PA server where the latency had crept up over time, and a third was running the server with tsched=0 on an Audigy SE (CA0106) with a minimum latency of 200ms. without using adjust latency mode, pa server use maximum buffer size by default and latency is fixed at about 340ms for ca0106 which does not support 44100hz. so this is incorrect for pulse plugin to accept 200ms, in previous version of pulseaudio you can specify the fragment time and the number of fragments to achieve low latency. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
