Decode to and play from RAM memory

[audioamper]

I'd like to see an option to make the most of today's abundant RAM: allow the user to decide how much memory can be used, then decode the audio file to RAM and play it from there. This would make life a (tiny, I know) bit easier on hard disks. Also, some purists mention that wav playback (file is already decoded) from RAM can actually sound better, possibly because of no moving parts etc.

[MrSinatra]

I'd like to see an option to make the most of today's abundant RAM: allow the user to decide how much memory can be used, then decode the audio file to RAM and play it from there. This would make life a (tiny, I know) bit easier on hard disks. Also, some purists mention that wav playback (file is already decoded) from RAM can actually sound better, possibly because of no moving parts etc.

i know there are some settings in prefs for this already, but what i'd like is the ability to load not only the entire currently playing file in RAM, but also the next file in the playlist.

[audioamper]

i know there are some settings in prefs for this already, but what i'd like is the ability to load not only the entire currently playing file in RAM, but also the next file in the playlist.

Do you mean the "Full File Buffering" option, in the MPEG Audio Decoder Settings? What about FLAC and other formats?

[MrSinatra]

i don't know, b/c i don't know what exactly that does, b/c i don't understand the general process itself, as to how it really works.

but i can tell you that what i want, is each file now playing, as well as the next one to be played, are fully decoded to wav in RAM, so crossfading and beat matching is seamless and disk access unnecessary beyond the initial file reading into memory.

i am hopeful such a system would solve my BUG #1 in my sig, since everything would be queued in RAM.

i would want that for ALL formats.

[thinktink]

As far as pre-loading the entire next song, it may not be practical.

You have to remember that the driving force behind audio playback is the input plugin that is used to decode the audio file. Since not all files are decoded by the same plugin there would have to be a new (and supported) mechanism (or a transparent addition to the current one that won't break for current plugins) for the plugins to be told what file is next and all the plugins rewritten to support that new mechanism. Having only written 2 input plugins I can't really speak from authority so take what I say with a grain of salt.

Loading the entire file of the current song is something that would be done by the current input plugin. I know in_mp3 can do some pre-loading/caching/buffering but the extent to which it does I don't know. There is an option in it [Preferences]->[Plugins]->[Input]->[Nullsoft MPEG Audio Decoder]->[Configure]->[General tab]->[Full File Buffering].

[MrSinatra]

As far as pre-loading the entire next song, it may not be practical.

You have to remember that the driving force behind audio playback is the input plugin that is used to decode the audio file. Since not all files are decoded by the same plugin there would have to be a new (and supported) mechanism (or a transparent addition to the current one that won't break for current plugins) for the plugins to be told what file is next and all the plugins rewritten to support that new mechanism. Having only written 2 input plugins I can't really speak from authority so take what I say with a grain of salt.

you're way ahead of me, i assure you. but i am confused. why does it matter if there are differing filetypes, since winamp will play them intermixed now? crossfading seems to work with it all now, no?

i don't use beat-mixing, i'm waiting for a plugin that does it well. i've seen DJ software that does it really well, back in 99, so its overdue imo. but i'd only overlap the songs 2-3 seconds at the most anyway.

in my case, most are mp3 anyway, like at least 90%.

Loading the entire file of the current song is something that would be done by the current input plugin. I know in_mp3 can do some pre-loading/caching/buffering but the extent to which it does I don't know. There is an option in it [Preferences]->[Plugins]->[Input]->[Nullsoft MPEG Audio Decoder]->[Configure]->[General tab]->[Full File Buffering].

does it load and decode the whole file in RAM?

i wish i could tell it to do the same for the next file in the playlist.

this is confusing too, b/c in my sig bug link DrO says the way to get short files to play is to shorten the buffer size below the file size, which i obviously don't consider viable.

anyway, interesting convo...

[thinktink]

...why does it matter if there are differing filetypes, since winamp will play them intermixed...

Not so much differing filetypes but different input plugin. For example, MP3 and AAC files are both handled by in_mp3 but WAV files are handled by in_wav, so on and so forthe. So for example say you have an MP3 file then a WAV file: some how the WAV handling plugin would need to know 1) What the next song is, and 2) Whether or not it can handle it, and all before the MP3 file finished playing. There currently isn't a mechanism in the input plugin API to allow that (as far as I know.)

crossfading seems to work with it all now, no?

At the output plugin yes, but output plugins don't control input plugins (except for how often buffers are sent to it.)

does it load and decode the whole file in RAM?

If I'm interpreting the description correctly, yes, but only if the file is smaller than the number of bytes specified in the input box.

i wish i could tell it to do the same for the next file in the playlist.

Aye, but that would only work if the next song is also handled by the same plugin currently handling the currently playing song.

this is confusing too, b/c in my sig bug link DrO says the way to get short files to play is to shorten the buffer size below the file size, which i obviously don't consider viable.

Buffer size is not the same as pre-buffering/loading songs that are smaller than that value specified. So what DrO said still holds true.

[ujay]

You need to distinguish between input and output buffers here.

The input buffer(set in the input plugin) is where the file is decoded from, the output buffer(set in the output plugin) is where the decoded output is sent too.

When DrO talks about shortening the buffer, he is referring to the output buffer. This is where Xfading, silence detection/gapless playback etc. happens .

UJ

[the SASS Man]

Wouldn't it make sense to have an overview process that monitors the playlist, Queue, etc., and simply requests decoded data from the correct plugin for the "next" item in the playlist, and then have the OUTPUT plugin receive all of its data from the overview process? This would eliminate any conflict between input plugins; allow pre-buffering of ANY arbitrary length; and eliminate the problem of "short" audio files not playing; because the output plugin would never see, nor interact with, the input plugins directly.....

Something to think about.

-- the SASS Man