i hope not being rude, but i need some latency performance fixes:
i need to be able to jump to some position in song (after receiving interrupt), but not in pieces of 26 ms (1 frame), but within each frame also, in accuracy of less than 5 ms. also, the latency between getting the interrupt request and the jump itself will have to be even less than that. also, when trying to jump, i got distorted sound for a few ms, and you adviced to set mute the sync and a few frames before the desired position. but this adds more latency ! how can i jump directly to the desired position without making this artificial fix, and ths without any latnecy ?
can you make the latency performance better, in the next patches ?
thnaks alot
Gad
-----Original Message----- From: mad-dev-admin@lists.mars.org [mailto:mad-dev-admin@lists.mars.org]On Behalf Of Rob Leslie Sent: Saturday, February 03, 2001 7:28 PM To: mad-dev@lists.mars.org Subject: Re: [mad-dev] mad performance question
Gabriel Bouvigne bouvigne@mp3-tech.org wrote:
Do you mean that right now, mad only try decoding at the seek
offset without
trying to get teh previous data necessary for decoding (like
previous frames
when main_data_begin>0)?
Right now, madplay only supports seeking via the -s option, which works by reading headers (only) until the given time is reached. It does not fully decode any frames prior to this point, nor does it preload the main_data buffer with anything from the skipped frames.
The plug-in for Winamp works slightly differently; it supports full seeking to any arbitrary location during playback. Once the seek location is found, a few frames are read in order to sync with the new stream position, pre-load the main_data buffer, and prime the IMDCT overlap outputs. Then, subband synthesis is performed once on the latest frame to prime the filterbank; the PCM result from this is discarded. Normal decoding and playback then resumes.
More precise positioning would indeed need more effort to properly decode frames preceding the seek point.
Cheers, -rob