[haiku-inc] Re: Contract Proposal: Streaming Support and Media Kit Development
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-inc@xxxxxxxxxxxxx
- Date: Sun, 28 Feb 2016 15:30:38 +0100
Hello,
* Improve media kit latency system investigating the introduction of the
notion of min/max latencies (relates #7285). This is needed as our
currently latency management isn't probably enough adequate to support
best effort services from the internet.
Given the past discussions about this topic, I'm not sure if we're all on
the same page regarding those. I would rather like to leave this out at
first, and discuss this - in detail - with our other developers, and only
if a consensus can be found, implement that one.
[...]
I'm OK with that. On the later discussions there was a bit of acceptance
relating the idea to implement a more complex latency management system.
I've been introducing the idea of having an activation table and a
log/timestamp system behind that would help nodes to understand what it's
happening. On various sides I think this will help on getting away from
some recurring bugs and enforce a strict policy on nodes synchronization.
When having to do with streaming and possibly complex processing paths
there are a bit of problems we have to resolve to ensure some reliable
performance.
* The game_kit is using a custom audio producer, it should use
BSoundPlayer or BMediaClient.
Would anything change regarding the output, and configuration options? Ie.
would there still be a single output channel?
I'm going to get the BMediaClient API in a good shape so I'll show it in
the next days. I've developed originally the idea for this API for two
applications I've developed and are in experimental status (e.g.
libjackcompat, Faber). What I needed at some point of the development is a
strong audio engine very similar to some degree to what the audio Mixer
already do but in a more flexible way. Additionally this class is designed
to overcome the current limitations of SoundRecorder (it can't play the
sound while registering). So the output/input configuration once the class
is complete will not matter and I think there will be no reason for having
code duplicated. One of the goals of this API is to make possible things
which are now much difficult to do. For example let's imagine you want to
record and play the output of SoundRecorder at the same time, with
BMediaClient you have to do two things :
* Use BMediaClient::BeginConnection() to obtain one or more
BMediaConnection(s) to
notify the media_server you have a new output/input available.
* Use BMediaClient::Bind with two node's connection to bind the data
received from one input to N outputs or the inverse depending on your needs.
* Figure where you want to connect that connection and use
BMediaClient::Connect()
* Call BMediaClient::Start(), from that point on your class will begin to
call the hooks.
* MediaPlayer can take advantage of it to reduce the code base.
The MediaPlayer does a lot more than it has to, but so far, AFAIU stippi
wasn't really keen pursuing this, so I think we should get his green light
on your plans first.
Since I'm going to put work into the class I've described before, I think
there are two advantages here in using that for the node framework, the
first is code duplication, the second is more flexibility on adding
processing abilities to that framework. Just as the example before, if I
want to add another output to MediaPlayer's sound producer I have to just
call a few functions to configure a secondary output for it. I'm of course
anyway available for everyone want to discuss it.
Depending on how much time fixing the previous tasks will take, I'm
planning to work eventually on the following points:
* Introduce and finalize the new MediaPlayer plugin API
* Add id3 tags support (#9525, ArmyKnife as plugin?)
* Work towards more stability for the media_server (#6220)
How about adding embedded subtitle support, too? [1]
I think it's feasible too, but I'm not in confidence with it. It will be
helpful if we get in a discussion about how it was already planned to
implement it so that I don't lose hours in figuring out it myself.
I will appreciate if it's possible to have the final decision made
before Monday.
That'll be tough given our previous track record, but with the
restrictions mentioned above, you'd have my +1.
I'm here anyway to discuss and refine the contract proposals for everyone
has something to say, thanks for giving feedback anyway.
--
Best Regards,
Dario
Other related posts:
