Opened 17 years ago
Closed 16 years ago
#5761 closed patch (fixed)
mythmusic bufferring is too aggressive
| Reported by: | Mark Spieth | Owned by: | stuartm |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.22 |
| Component: | mythmusic | Version: | head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
mythmusic currently buffers until the output buffers are full causing delays when any play parameters are changed.
this has been in my set of patches for ages.
patch attached
Attachments (2)
Change History (5)
by , 17 years ago
| Attachment: | mm_buffer.1.patch added |
|---|
comment:1 by , 17 years ago
| Milestone: | unknown → 0.22 |
|---|---|
| Owner: | changed from to |
| Status: | new → accepted |
| Version: | unknown → head |
comment:2 by , 17 years ago
in audiooutputbase I previously had a 2 sec limit but this impacted video playback as some videos have a reasonable delay and if you also use sync adjust this can cause it not to work.
so the solution I came up with is to manage the amount buffered in the data feeder of which there are 4 in mm. this means when you change timestretch in mm it acts immediately (0.5 sec) instead of after 10-15 secs which was pretty crap.
dumping the buffer on stop/track change is probably a good idea but it seems to work fine anyway. just that the track change occurred 10-15 secs before you hear it. I wouldnt worry about this with the limit in place.
by , 17 years ago
| Attachment: | music-buf-r20533.patch added |
|---|
Updated patch to take into account files that have since been removed from trunk. Untested.
comment:3 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
Thanks Mark, I've been meaning to fix this one lately. Is reducing the buffering the right solution? Although I was yet to look at the problem, I was thinking of just dumping the buffer as we would on a normal mid-track change and just fix the problem of not being able to make that switch after decoding was complete.