Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#7213 - Align audio data reading in the playback engine to even addresses

Attached to Project: Rockbox
Opened by Toni (ahellmann) - Saturday, 26 May 2007, 08:30 GMT+2
Task Type Feature Requests
Category Music playback
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

In the current playback system after reading an odd
length audio (mp3) file all following ata reads for
the next audio file have to deal with unaligned read
buffers. This reduces the file reading speed on many
(all?) targets. I could solve this issue with
following lines in playback.c:

/* rc is the actual amount read */
rc = read(current_fd, &filebuf[buf_widx], copy_n);

/* align audio filesize, faster ata reading (even address) */
if(rc > 0) rc = (rc + 1) & ~1;

This align looks a little bit dangerous, so I am not
sure, wether it works for all audio input formats.
This task depends upon

Closed by  Björn Stenberg (zagor)

Reason for closing:  Fixed
Additional comments about closing:  Closing all feature requests.
Comment by Boris Gjenero (dreamlayers) - Thursday, 09 April 2009, 07:27 GMT+2
With r20646 I don't see how an odd-sized read can cause loss of alignment. Buffering code normally reads BUFFERING_DEFAULT_FILECHUNK bytes at a time, and that is even. Reads can be shorter at the end of the file or at the end of the buffer, where the buffer wraps. Short reads at end of file aren't a problem because add_handle will align the next handle address. The start and end of the buffer is aligned, and the number of bytes between an aligned reading position and the end of the buffer must be even, so wrapping must preserve alignment.

While working on PP502x ATA DMA in  FS#9708  I noticed another alignment issue. What matters is not alignment of the reading position, but alignment of sector boundaries. For example, a read starting at file offset 3 is unaligned when the buffer is at address 0 and it is aligned when the buffer is at address 3 or 7. This can happen with ID3v1 in MP3 files. For example if an MP3 file has an odd sized ID3v1 at the start, the entire file will be read unaligned. The buffer_align patch at  FS#9708  performs this alignment. PP502x DMA requires word alignment (divisible by 4), so that is the kind of alignment done by that patch. I don't know if it is safe for all codecs in all situations.

Alignment also depends on sizeof(struct memory_handle). If that was odd, file data would start at an odd address. However sizeof(struct memory_handle) is not odd.

Aligned and unaligned disk transfer rates may be compared at: http://www.rockbox.org/twiki/bin/view/Main/DiskSpeed

Loading...