Basic music player with Membrane

serpent

First, thanks to the Membrane team for creating this awesome framework!

Based on SimplePipeline I’m trying to build a simple music player. Following functionality is required:

Start playback from file, get notification on finish
- use handle_element_(start|end)_of_stream/4 hooks on sink
Get current playback position
- Save Time.monotonic_time() on playback start and calculate difference to now?
Nice to have: play/pause
- Possible with the soft-corking patch?

I made some experiments on how to get the current timestamp. First intuition was to create a :tick timer and then query the current time from the sink – couldn’t quite figure it out, yet.

For some reason the timer runs very unsteady. My above example gives me (expected interval: 5000, off is a factor):

handle_element_start_of_stream:
16:03:34.304 [debug] Membrane.Demo.SimplePipeline/:portaudio received start of stream
:portaudio
:input
===============================
handle_tick:
:tick
last_tick: -576460742608535951
interval: 5068.75382 (off 1.013750764)
===============================
handle_tick:
:tick
last_tick: -576460737539782131
interval: 2.763771 (off 5.527542e-4)
===============================
handle_tick:
:tick
last_tick: -576460737537018360
interval: 2148.508728 (off 0.42970174559999996)
===============================
handle_tick:
:tick
last_tick: -576460735388509632
interval: 2558.596995 (off 0.511719399)
===============================
handle_tick:
:tick
last_tick: -576460732829912637
interval: 2535.085853 (off 0.5070171706)
===============================

My clock subscription does not seem to have any effect.

When terminating the pipeline (Pipeline.terminate) and starting it again, I start to notice artifacts in the output, everything seems to slow down. CPU load is <5%, though. Is there anything else to do for a clean restart?

Sincerely,
Steffen

3 comments

/membrane #audio

4 1621 3

2023-09-03 21:38:12 UTC

First 3 of 3 Posts

WojciechBarczynski

Membrane Core Team

Hi
Usually, business logic like the one you described is handled in filter elements, rather than in the pipeline itself.

Assuming your audio files have correct PTS values (or that they are somehow adjusted before entering the business logic element), you can easily read timestamps from buffers.

In your case, I would simply use handle_info in Pipeline to receive application event (like pausing/playing), pass notification to custom element with notify_child and handle it there on handle_info.
In case of pausing/playing audio, you can enqueue your audio in the element state if needed.

Post #2

serpent

Thank you, Wojciech!

MP3s don’t carry PTS stamps, it seems. But counting the raw buffer bytes in the filter seems to work, then dividing by the number bytes per second.

In case of pausing/playing audio, you can enqueue your audio in the element state if needed.

You mean, my element just stores all the incoming data and just doesn’t pass it on in case of pausing? Wouldn’t it make sense to use the demand functionality instead? Or is it not meant for this purpose?

Post #3

WojciechBarczynski

Membrane Core Team

Hi, sorry for the late response.

Element in the pipeline can operate in three flow control modes - “auto”, “manual” and “push”. If you expect long pauses, you are right that it would be better to use “manual” mode to prevent any extensive data accumulation and memory consumption. You will need to implement handle_demand in such case.

Keep in mind, that if previous elements work in “push” mode (e.g. some elements receiving data via the network connection without flow control), Membrane will still enqueue them under the hood (basically it’s impossible to handle that without dropping buffers), which may result in toilet overflow error.

Post #4

— All posts loaded —