Elapsed Duration functionality for the Decoder/LoopedDecoder #510
Conversation
There was a problem hiding this comment.
Love that you are adding this! I have wanted it for a while, my current workaround is guessing the time between pausing and playing however that has a ton of issues.
I am also adding seeking support to rodio. It would be very nice if I or someone else could use that and this to fix: #443. For that we would need the elapsed_duration inside:
Line 21 in eda5934
Is it possible to change the API/approach to this such that the elapsed_duration could be used there?
It could also be nice if we could access the current elapsed duration for the source currently playing in a Sink.
Again thanks for contributing!
edit: now that I think about it it would also make testing seek way easier! :)
|
|
||
| #[inline] | ||
| pub fn elapsed_duration(&self) -> Option<Duration> { | ||
| Duration::try_from_secs_f64( |
There was a problem hiding this comment.
forgive me but why do we return an Option here? is there a combination of elapsed_samples, sample rate and channels that makes try_from_secs_f64 fail? I would love a comment explaining that.
Or is it there because some combination of sources could not support elapsed_duration?
| } | ||
|
|
||
| #[inline] | ||
| pub fn elapsed_duration(&self) -> Option<Duration> { |
There was a problem hiding this comment.
This might not be the best name, elapsed sounds like its the time since the song started playing, however it is the position of the song right? So maybe name it .... position, playback_pos or something else
Cause this could get confusing with seeking.
|
This might fit better as a new method on The bigger question is what to do about |
|
Really nice! Am using rodio for a small music app, and would be very helpful to have this feature. |
|
Note for myself in the future: Implement this through adding a new source wrapping whatever is beneath.
Anyone should feel free to try something like this, I do not have the time atm. I do need this feature for a hobby project so I will implement it eventually, tho that could be in a few months. |
|
@dvdsk Ah, should have read more carefully, I assumed the current state of the PR is mergeable, since the most recent comment was just a few weeks old. I could try to make a new PR based on the design you just outlined, but am afraid the architectural design decisions are a bit out of my comfort zone as I'm quite unfamiliar with the library. With a slightly more detailed set of instrucitons can definitely attempt to do this. |
|
I haven't looked at this in a while, but I can also later this week take a look at the requirements and see how the features could be implemented. |
I recommend taking a look at the text here: https://docs.rs/rodio/latest/rodio/source/trait.Source.html, browse a few of the structs implementing Line 120 in ee73f6d That should give you a feel for the relevant part of the code base. Then you or @BastianHentschel can give it a try. Let me know if its still unclear after reading up, then ill write up some pseudo code. |
This adds a new PositionTrack trait which counts the amount of times `next()` is called (where it returns `Some`) and provide a function to get the position, which is a simple calculation. This is added to the Sink struct by default and the accuracy of this depends on the interval of `periodic_access`. I wasn't able to add testing to the sink counter part, because I wanted to also test `try_seek`, but it seems like I would need to have some threading code to call `next` on sink in another thread, which didn't look that good and resulted in a flaky test so only a 'unit test' in ``position.rs`. Resolves RustAudio#457 Closes RustAudio#510
This adds a new TrackPosition trait which counts the amount of times `next()` is called (where it returns `Some`) and provide a function to get the position, which is a simple calculation. This is added to the Sink struct by default and the accuracy of this depends on the interval of `periodic_access`. I wasn't able to add testing to the sink counter part, because I wanted to also test `try_seek`, but it seems like I would need to have some threading code to call `next` on sink in another thread, which didn't look that good and resulted in a flaky test so only a 'unit test' in ``position.rs`. Resolves RustAudio#457 Closes RustAudio#510
This adds a new TrackPosition trait which counts the amount of times `next()` is called (where it returns `Some`) and provide a function to get the position, which is a simple calculation. This is added to the Sink struct by default and the accuracy of this depends on the interval of `periodic_access`. I wasn't able to add testing to the sink counter part, because I wanted to also test `try_seek`, but it seems like I would need to have some threading code to call `next` on sink in another thread, which didn't look that good and resulted in a flaky test so only a 'unit test' in ``position.rs`. Resolves RustAudio#457 Closes RustAudio#510
|
Hi, I've gone ahead and implemented what was described in #510 (comment) over at #585 |
Ill have a look tomorrow 👍 thanks for the work! Since that effort supersedes this I am gonna close this PR for now and move the discussion there. |
The commits add a member to the Decoders, which contains the required information for the elapsed duration.
The functionality is implemented in the
impl<R> Iterator for Decoder<R>/LoopedDecoder<R>and ticks an AtomicUsize up each read sample. With the channel count and sample rate the effective elapsed duration of a Decoder can be calculated.