Opened 16 years ago
Closed 15 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)
Changed 16 years ago by
Attachment: | mm_buffer.1.patch added |
---|
comment:1 Changed 16 years ago by
Milestone: | unknown → 0.22 |
---|---|
Owner: | changed from Isaac Richards to stuartm |
Status: | new → accepted |
Version: | unknown → head |
comment:2 Changed 16 years ago by
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.
Changed 15 years ago by
Attachment: | music-buf-r20533.patch added |
---|
Updated patch to take into account files that have since been removed from trunk. Untested.
comment:3 Changed 15 years ago by
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.