Properties to suppress save/restore of stream volumes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



'Twas brillig, and Tanu Kaskinen at 03/02/11 07:16 did gyre and gimble:
> On Thu, 2011-02-03 at 08:34 +0200, Tanu Kaskinen wrote:
>> I would personally just request lower latency when using cross-fade in
>> RB, but then again, I don't use cross-fading in the first place, and I
>> don't run RB in any power-challenged device, so I may not be the best
>> judge here. It would be nice to fix gstreamer to support rewinding, or
>> maybe implement a fading module in Pulseaudio that could be accessed
>> through pulsesink in gstreamer, but those are probably more work than
>> you're willing to do. I don't oppose having your patch in Pulseaudio,
>> with the suggested changes.
> 
> In that quoted paragraph, I say "I would personally just request lower
> latency". I changed my mind. Unless I was in a hurry for some strange
> reason, I would actually choose to do a fading module in Pulseaudio if I
> had to solve this cross-fading problem. That's because doing
> cross-fading is a recurring feature in music players, and with large
> buffers rewinding is necessary for responsive cross-fading track
> changes. If music players can get away without implementing rewinding in
> their own code, that means that a lot of work is saved (I believe
> implementing rewinding is generally quite tricky).

I was just reading your last mail and was about to suggest that we
consider some kind of xfade module in PA itself which we could give two
streams and have it handle the fade. Now you've beaten me to it!

I guess the real problem would be how to interface with xfade in gst
such that gst applications would be essentially ignorant of "how it's
done", such that gst-on-alsa works as transparently (to the app) as
gst-on-pulse.


I'm not sure how this would work in practice at the PA end, but I would
guess some kind of protocol/API extension (as is done for m-s-r and
m-d-m right now) rather than a part of the core protocol (but perhaps
this would be justified?).

That said, I'd like to make writing protocol extensions much easier in
code. It's a bit of a PITA just now and requires putting hooks in
various bits of the code to deal with it. I'd rather make that more
dynamic if possible.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux