Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

Overview
Memory playback now holds decoded data in memory instead of encoded data.

This means playing any form of lossless (WAV, FLAC, APE, ALAC, etc.) will have identical data in memory and identical resource usage.

Benefits
The theoretical benefits of memory playback are that no disk or network I/O occurs while playing and that CPU load during playback could be reduced.

Technical Considerations
With a modern computer, playback of a standard CD-quality file will have the fully decoded file in memory in around one second.

Memory playback will use up to 1GB of memory for cache (capped at 80% of available system memory to avoid swap usage).

In some cases, the work of decoding and caching a file quickly as a track starts could lead to other problems.  For example, when playing over Wi-Fi some machines exhibit high resource usage when reading a file quickly.  This resource usage as a track starts could lead to audio playback glitches.

Some files like DSD played as PCM have very large decoded data so that they might require more memory to cache than (most) any system has.  In these cases, the program will cache 1GB, play it mostly out, then cache another 1GB, etc.

With memory playback enabled, the player will no longer report a real-time bitrate (ie. 872 kbps) during playback.  This is because asking the decoder its current bitrate is not possible when the decoder has finished with the current track completely in the first couple seconds of playback.

Sound Quality
JRiver is unaware of any test that shows a sound quality advantage to memory playback. 

The option was added due to popular demand.

How to Use
You enable or disable memory playback in Options > Audio > Play files from memory instead of disk.

It is off by default.

[fitbrit]

Nice. I will keep this option off. Hopefully, this will either bust a few myths or let people hear the difference they've been wanting. Win-win.

[mojave]

The decoding seems to be almost instantaneous on my PC. This feature will also allow people to see how fast decoding really happens.

[rayooo]

Fantastic!!!! thanks. 

[Vincent Kars]

Memory playback will use up to 1GB of memory for cache (capped at 80% of available system memory to avoid swap usage).

Nice to see JRiver having true memory playback
I wonder why you put a hardcoded constrain on it.
Can imagine that a user run Win64 with 8 GB could use a higher value.
Why not making it a user configurable parameter?

[bulldogger]

Overview
Memory playback now holds decoded data in memory instead of encoded data.

This means playing any form of lossless (WAV, FLAC, APE, ALAC, etc.) will have identical data in memory and identical resource usage.

Benefits
The theoretical benefits of memory playback are that no disk or network I/O occurs while playing and that CPU load during playback could be reduced.

Memory playback will use up to 1GB of memory for cache (capped at 80% of available system memory to avoid swap usage

Some files like DSD played as PCM have very large decoded data so that they might require more memory to cache than (most) any system has.  In these cases, the program will cache 1GB, play it mostly out, then cache another 1GB, etc.

With memory playback enabled, the player will no longer report a real-time bitrate (ie. 872 kbps) during playback.  This is because asking the decoder its current bitrate is not possible when the decoder has finished with the current track completely in the first couple seconds of playback.

Sound Quality
JRiver is unaware of any test that shows a sound quality advantage to memory playback. 

The option was added due to popular demand.

How to Use
You enable or disable memory playback in Options > Audio > Play files from memory instead of disk.

It is off by default.

So 1 GB is the most that would be in memory regardless of how muck memory I have? If so adding a large amount of memory like 16GB or 32GB would offer no improved capability beyond the 1GB?

[Hendrik]

So 1 GB is the most that would be in memory regardless of how muck memory I have? If so adding a large amount of memory like 16GB or 32GB would offer no improved capability beyond the 1GB?

MC is a 32-bit application and as such its total memory usage is limited, it would never be able to use this much memory.

[6233638]

Nice to see JRiver having true memory playback

It already did have "true" memory playback, playing from a buffer of decoded audio. But it now buffers 1GB which will allow most(?) tracks to be fully decoded into memory.

Can imagine that a user run Win64 with 8 GB could use a higher value.

If I recall correctly, a 32-bit application should be able to use ~3GB on a 32-bit OS and ~4GB on a 64-bit OS.

Moving to 64-bit would likely add a number of issues and incompatibilities. (e.g. no high quality video playback, lower compatibility with VST plugins)

Why not making it a user configurable parameter?

I agree, it would be nice if this were user configurable.

[Vincent Kars]

It already did have "true" memory playback

Are you sure? See Matt's opening post, the decoding before playback started is one of the new features IMHO

[rayooo]

Are you sure? See Matt's opening post, the decoding before playback started is one of the new features IMHO

Agreed..that's what I thought as well...  The "old" play from memory cached the raw disk data in ram, then, decoding, resampling etc. was performed during playback.

The new play from memory does all decoding, DSP operations etc, caches this result in ram .. And then begins playback.  Do I have this roughly correct???

[Matt]

Both MC18 and MC19 have true memory playback in that there's no disk I/O during playback.

MC19 moves decoding to the front side instead of doing it on the fly.  This moves about 1 or 2 seconds of CPU time spent decoding to the start of playback instead of spreading it smoothly over the course of a song.  This means all forms of lossless are completely identical in memory and with regards to resource usage during playback.

[Vincent Kars]

This means all forms of lossless are completely identical in memory and with regards to resource usage during playback.

Anybody still hearing a difference is need of tweaking his placebo a bit better

[kstuart]

Oops - missed the word "still", so never mind.

[InflatableMouse]

If I recall correctly, a 32-bit application should be able to use ~3GB on a 32-bit OS and ~4GB on a 64-bit OS.

Under normal circumstances, a 32-bit program on 32-bit OS can allocate 2GB of RAM. The remaining 2GB is allocated for the OS. Unless the hardware doesn't support relocating hardware addresses to above 4GB barrier, then the user space gets less, usually between 256MB and 768MB less. Its also possible to configure the OS to use 1GB instead of 2, and the user space gets that 1GB extra. This is not something that's automatic or enabled by default, it requires the user to set "increaseuserva" parameter via bcdedit on Vista and above, or /3GB switch on XP. Limiting the OS to 1GB can also lead to problems although I admit its not very common, problems mostly arise on terminal servers/citrix environments.

On a 64-bit OS a 32-bit program should in theory be able to allocate the full 4GB of RAM that 32-bit can allocate (2^32).

Note the "in theory", because I have no idea if it requires major changes in code and whether that breaks true 32-bit compatibility for instance.

[jmone]

Anybody still hearing a difference is need of tweaking his placebo a bit better

  Anyone hearing a difference before also needed said tweaking!

[ths61]

Overview
Memory playback now holds decoded data in memory instead of encoded data.

This means playing any form of lossless (WAV, FLAC, APE, ALAC, etc.) will have identical data in memory and identical resource usage.

Benefits
The theoretical benefits of memory playback are that no disk or network I/O occurs while playing and that CPU load during playback could be reduced.

Sound Quality
JRiver is unaware of any test that shows a sound quality advantage to memory playback. 

The option was added due to popular demand.

Thanks much. 

This feature should make a lot of customers happy and end a lot of debates.

[Veovis]

On the two computers I've had since I started using J River, memory playback has only had a negative effect on SQ in my ears. I have frequently tested it but have always ended up leaving that particular box unticked. But it will be interesting to see (hear) if the new implementation improves things. I definitely prefer Pure Music on the mac in memory playback mode and I believe that player decodes the audio files before putting them in memory. Same with Audirvana which is also a very good sounding audio player for the mac.

Either way, I'm really happy with the way MC 18 sounds without using memory playback so I won't be very disappointed if the new implementation of memory playback doesn't add anything. And I use wav with MC anyway, so the theoretical advantages compared to the old implementation should be even less noticeable.

Anyway; thanks for continuing to develop this great piece of software. I'm happy to continue my support by upgrading to 19.

[Blaine78]

this is fantastic!

[ead1]

Can we have JRiver that is 64 bit??
And choose the MAX size of the memory use for songs? I have DSD files of 128DSD or 24/192 files of FLAC and such, I want them to be fully decoded in the memory, even it use 2GB of memory or more!

I have 16GB of memory and no problems of upgrading it to 32GB, so no issues here, so?

Can it be done?

That will be great!

[Hendrik]

Can we have JRiver that is 64 bit??

Last time it came up, 64-bit was not planned yet. Maybe in a future version, but i would not expect it for MC19.

[ead1]

Last time it came up, 64-bit was not planned yet. Maybe in a future version, but i would not expect it for MC19.

Why is that?! isn't it about time to have both 32 bit and 64bit versions??

[6233638]

Probably because moving to 64-bit breaks compatibility with a lot of plugins - including madVR - and because there's no audible benefit to using memory playback.

[Arindelle]

and because there's no audible benefit to using memory playback.

Just my 2 cents, I was involved in a group ABX testing, which totally backed up what 623 is saying so I never bothered with it anyways (no debate, everybody has a choice of course).

However, I decided to try it on a client playing music remotely on a PC, and although no noticeable audio improvement as expected, but I thought it made my network connection  faster ... is this possible or is this a placebo effect, I don't know. Seems obvious when searching within a song. But I also noticed an increase of speed before -- maybe it has more to do with the dev's work to increase this in the last couple of months/versions

Btw, Server is still configured without memory playback and sounds great on my stereo, so I don't see why I would change that.

[6233638]

However, I decided to try it on a client playing music remotely on a PC, and although no noticeable audio improvement as expected, but I thought it made my network connection  faster ... is this possible or is this a placebo effect, I don't know. Seems obvious when searching within a song. But I also noticed an increase of speed before -- maybe it has more to do with the dev's work to increase this in the last couple of months/versions

The way that memory playback works in MC18 is that it caches the entire file in memory, and then has a buffer of ~40MB for decoded audio during playback.

This means that when you seek through the file, it will be accessing it directly in memory, rather than relying on network access, which explains why it would be faster to seek through a track.

The downside to using memory playback over a network is that you may have a slight delay during track changes if your network is slow to respond, because all the network activity happens at the start of a track.
If you are streaming the track (memory playback disabled) then the connection is in use throughout playback, and should still be "open" when the track changes, so you may have less delay.


Media Center 19 has made a number of changes to the way that memory playback works, that satisfy the audiophile requests for "real" memory playback, but I think it negatively impacts performance in a number of ways, for no audible benefit, and it's now possible for a track to only be partially cached if it exceeds the ~1GB buffer when decoded.

[Arindelle]

thanks for the info 623 

[kstuart]

Warning - some of you will want to close your eyes....




There was an extensive blind test that showed audibility.

Okay, it is now safe to go back to your abstract fantasy world where everything is the way it ought to be, and everything can be measured.

[phusis]

Warning - some of you will want to close your eyes....




There was an extensive blind test that showed audibility.

Okay, it is now safe to go back to your abstract fantasy world where everything is the way it ought to be, and everything can be measured.

+1

I'm happy 'Improved memory playback,' among other features mentioned, is incorporated in MC19. Upgraded already - looking forward to its release...

[WeatherB]

Glad to hear that! When I first used MC 19 today, I noticed an small improvement in sound quality and wondered if it was just my imagination. 

[rayooo]

Knock-on-wood the new mem play works wonderfully on my desktop.  very little delay.

Random track changes to 44k (Flac) are virtually instant play.  88k and up takes maybe 1/4 to 1/2 second tops.  no muss, no fuss.
(connection is via wired Gig-E to Synology NAS)

Oh and it sounds wonderful also. 

Having said the above, guarantees I'll have trouble when I put 19 on the main player. 

[6233638]

Is no-one else having problems with the new memory playback—particularly with DSD?

I can’t use memory playback any more, because it has 100% CPU usage for ~20 seconds every time the track changes, and it makes seeking slower instead of being instant like MC18 because it has to buffer all the time.

It also uses 2–4x the RAM for no benefit. It's a major issue.


Does everyone else just have a system dedicated solely to music playback and not actually use their PC for anything else at the same time?

[rayooo]

Is no-one else having problems with the new memory playback—particularly with DSD?

I can’t use memory playback any more, because it has 100% CPU usage for ~20 seconds every time the track changes, and it makes seeking slower instead of being instant like MC18 because it has to buffer all the time.

It also uses 2–4x the RAM for no benefit. It's a major issue.


Does everyone else just have a system dedicated solely to music playback and not actually use their PC for anything else at the same time?

I don't have DSD (yet) all PCM/WAV currently.  My main player is dedicated to audio, desktop is multi purpose with SPDIF output to cheapo DAC.  It's a multi use machine..but 16Gig RAM and way over powered for the need. 

near as I can tell simply using Windows Resource Monitor...   during track change, network usage goes from virtually zero up to approx 90Mbit/Sec and 10% utilization for a brief time.  CPU usage goes from 1% up to approx 4%, again, very briefly.   
Only other tasks going on are Email (Outlook) and Browser (Firefox)   

I'll check this info again on the main player (dedicated listening room player) and see what it shows. 
...PS I need to get a DSD Dac to play with.

[JimH]

DSD files are very big.  Loading from a slow drive or a network drive would be noticeable.

[InflatableMouse]

Is no-one else having problems with the new memory playback—particularly with DSD?

I can’t use memory playback any more, because it has 100% CPU usage for ~20 seconds every time the track changes, and it makes seeking slower instead of being instant like MC18 because it has to buffer all the time.

It also uses 2–4x the RAM for no benefit. It's a major issue.


Does everyone else just have a system dedicated solely to music playback and not actually use their PC for anything else at the same time?

I have one album in dff, SRV& DT, Couldn't stand the weather, so I figured I'd give it a swing. 2nd track loads 1,3GB in memory. It plays instantly and skipping is instant. I actually had to check memory playback was enabled because I expected at least some delay.

Edit: I'll recheck later, cpu is at 100% because analyze is running minimized.

[6233638]

DSD files are very big.  Loading from a slow drive or a network drive would be noticeable.

They're loading off a 4TB WDSE which is one of the faster hard drives around. (171MB/s)

The problem is that memory playback no longer caches the file it's playing in memory - it relies on disk/network access when decoded audio exceeds the 1GB buffer (common with DSD files) and DSD files require much more CPU than PCM to decode.
Because it's trying to fill 1GB of decoded audio as quickly as possible, you have maybe 20 seconds of 100% CPU usage (on a fast system - 5000 JRmark score) every time there's a track change or seeking occurs, and there's maybe 5-10s of silence as it buffers.

If I'm doing anything else on the computer, this prolonged CPU usage every time there's a track change interferes with whatever else I was using the system for.
In MC18 which cached the files in memory and used a ~40MB buffer, seeking was instant, CPU usage was about 20% at most (typically <1%) and I never had Media Center tell me that it was "buffering" during playback.

The largest single track I have is ~500MB (20 minute multichannel DSD file) which meant that MC18 had half the memory footprint of MC19. (typically much lower)
This seems like a serious regression in performance and usability just to tick off an audiophile checkbox.


The seeking issues would be solved if Media Center had a larger buffer that allowed the entire file to be decoded into memory (which probably requires a 64-bit build and more than the 8GB RAM I have) but that would then make the high CPU and memory usage even worse. As I understood it, JRiver's position was that memory playback should not have any impact on audio quality, so that seems like it would be heading in the wrong direction.

The best solution seems like it would be to make the size of the decoded audio buffer adjustable (so I can reduce it back down to ~40MB or whatever MC18 used, rather than 1GB) and to bring back the option of caching the file so that disk/network access is not a factor. The logical extension of that seemed like it would be to allow caching multiple files at once—even just two—so that disk access can never impact playback. (currently Media Center only starts loading the next file in the last ~10s of a track) Even with two tracks cached (the current and next one) memory usage would be lower than it is now.

PS I need to get a DSD Dac to play with.

I'm actually converting to PCM to take advantage of Volume Leveling.

[mojave]

Because it's trying to fill 1GB of decoded audio as quickly as possible, you have maybe 20 seconds of 100% CPU usage (on a fast system - 5000 JRmark score) every time there's a track change or seeking occurs, and there's maybe 5-10s of silence as it buffers.

I have 312 dsf files on an external USB hard drive. With memory playback, the files play instantly, seeking is instant, and changes to the next track are instantaneous. I have a 32-bit Windows 7 computer (3707 JMarks) with 3 GB of memory. JRiver only uses about ~600 MB even if I'm showing 2 Gb available. My CPU goes to 14% for two seconds before dropping back to 0, but playback is instantaneous.

I played my largest track (720 MB) and smallest track (77 MB) with no problems.

[6233638]

I have 312 dsf files on an external USB hard drive. With memory playback, the files play instantly, seeking is instant, and changes to the next track are instantaneous. I have a 32-bit Windows 7 computer (3707 JMarks) with 3 GB of memory. JRiver only uses about ~600 MB even if I'm showing 2 Gb available. My CPU goes to 14% for two seconds before dropping back to 0, but playback is instantaneous.

Are you bitstreaming, or converting to PCM? Are the files DST compressed? It's usually more problematic when downmixing from multichannel as well.

EDIT: I just realized that if they are DSF files, they will be uncompressed stereo tracks.
After checking this, it seems like the problem may only be with DST compressed tracks. (DSF is uncompressed, DST compression is optional with DFF stereo tracks)

What may also make a difference is that I have Media Center set to use the minimum ASIO buffer size (so seeking etc. should be instantaneous)

[mojave]

I am converting to PCM. Using ASIO with JRiver buffers set to "Minimum Hardware Size" works just fine.

It sounds like maybe DST compressed files will need to be handled differently.

[kstuart]

It also uses 2–4x the RAM for no benefit. It's a major issue.

If you don't receive a benefit, why not turn off the feature ??

[6233638]

If you don't receive a benefit, why not turn off the feature ??

Well in MC18 it meant that seeking was instant and disk I/O wouldn't affect playback.

[InflatableMouse]

If dsf isn't a problem you could consider converting them maybe?

[6233638]

If dsf isn't a problem you could consider converting them maybe?

Are there any tools to convert DFF to DSF? I could always re-rip, but anyone that's done that before, knows why I am reluctant to do so.
DSF files are limited to 2 channels, and DST compression saves you 50% space - which is a huge amount. (uncompressed DSD is much larger than anything else)
If anything, I'd rather be converting all my rips to DFF files with DST compression, and discarding the stereo tracks when there's a multichannel one available - but right now multichannel doesn't level properly when downmixed, and I don't have the option of bitstreaming that.

It just seems like Media Center has gone from being this nice efficient player, to wasting a gig of RAM for seemingly no benefit, and a number of performance regressions.
I don't even have to be doing anything complex on my system for the new memory playback to have an impact - if I'm playing anything using DST compression and scrolling a web page, it starts skipping every time there's a track change.
As I mentioned above, it seems like a better use of that RAM would be to cache the currently playing and next track in memory, instead of this huge buffer of decoded audio.

[InflatableMouse]

I'm afraid I can't really help you with that. I've played with SACD ISO's and I thought it was too much work and I didn't have time to read up on it. I still have the ISO's on disk, but for most of them I got the regular CD's ripped to Flac.

So while I admit I don't know anything about it and I'm probably not very helpful , but isn't it an option to convert sacd iso's with MC19 to DSD? I tried one track and the result is a dsf file which seems to be the same as as the bunch of dff files I have.

[6233638]

I'm afraid I can't really help you with that. I've played with SACD ISO's and I thought it was too much work and I didn't have time to read up on it. I still have the ISO's on disk, but for most of them I got the regular CD's ripped to Flac.

It's easy enough to go from SACD ISO to either DSF or DFF (sacd_extract will do it) but I don't know how to perform the conversion from one format to the other after that. If the tracks are uncompressed, I have already converted them to DSF (I prefer individual tracks to an ISO) but if they are compressed, I keep them as DFF files. Multichannel discs require the use of compression, and most stereo discs are uncompressed. It makes sense that they would be uncompressed just to fill out the disc, but it's a pain when you are trying to rip a collection and have to store the files.

So while I admit I don't know anything about it and I'm probably not very helpful , but isn't it an option to convert sacd iso's with MC19 to DSD? I tried one track and the result is a dsf file which seems to be the same as as the bunch of dff files I have.

As I understand it, Media Center's DSD conversion converts to PCM and then encodes to a DSD file. So you effectively double the noise on each track. (or try and filter out the noise, and add it back)


I don't see converting files and doubling their size on disk as a solution though - Media Center 18 had no problem with these files.
And even after conversion, they're still not going to fit into that 1GB buffer.

[kstuart]

So are you saying that the reason you don't want to just turn it off, is that you like the MC18 memory playback "that has no benefit", but not the MC19 memory playback "that has no benefit" ?

And by the way, real-time decompression of multi-channel SACDs is unquestionably the most CPU-intensive audio playback task.   Before Matt added the multi-threading, I had difficulty doing it at all with marginal PCs.

Lastly, SACDs that have multi-channel tracks and stereo tracks, often have different audio from different sources on the stereo track.  Sometimes, that means the stereo tracks have value.  Sometimes the multichannel tracks have been done better, sometimes the stereo tracks.  I like multichannel audio, but those tracks are not automatically better just because they are multichannel.  It varies from release to release, there are no reliable patterns.

[6233638]

So are you saying that the reason you don't want to just turn it off, is that you like the MC18 memory playback "that has no benefit", but not the MC19 memory playback "that has no benefit" ?

No audible benefit. MC18/19 sound the same whether memory playback is enabled in them or not.

In MC18 when you enable memory playback, seeking is instant with all files (as the entire file is cached in RAM) and disk/network I/O cannot interrupt playback. (e.g. multiple file copy operations running in another program) CPU usage is low, because Media Center is only trying to fill a ~40MB buffer.

In MC19 seeking is instant once the track has been decoded if it fits into the 1GB cache - but memory usage is much higher as it caches decoded audio rather than the compressed file.
When the decoded audio does not fit into memory (common with DSD) disk/network I/O can impact playback or seeking performance. CPU usage is very high when tracks change or you seek, because it's now trying to fill a 1GB buffer instead of 40MB.

In MC18 I bet you could play a track over your network, pull the plug, and it would play to the end. In MC19 the track might stop halfway through. (assuming it's a large DSD file)

I think MC18's memory playback was a much better design than we have now, and the only improvement it needed would be to cache both the current and next track, instead of only the current track - that gives you 3+ minutes to grab the next file, instead of ~10s.


In theory, MC19's memory playback feature could make playback less susceptible to interruption due to high CPU usage, but that has never been a concern for me, and the high CPU usage inside MC19 now interferes with other programs running on the system.

And by the way, real-time decompression of multi-channel SACDs is unquestionably the most CPU-intensive audio playback task.   Before Matt added the multi-threading, I had difficulty doing it at all with marginal PCs.

I have an i5 2500K running at 4.5GHz - it should not be an issue.

Lastly, SACDs that have multi-channel tracks and stereo tracks, often have different audio from different sources on the stereo track.  Sometimes, that means the stereo tracks have value.  Sometimes the multichannel tracks have been done better, sometimes the stereo tracks.  I like multichannel audio, but those tracks are not automatically better just because they are multichannel.  It varies from release to release, there are no reliable patterns.

Well that's part of the reason I've kept both so far. I still prefer converting to DSF/DFF files than SACD ISO though, as it means I can tag them properly. (and the metadata is stored in them with DSF files)

[Blaine78]

Immensely happy with the improved audio memory playback, and the other additional audio features in JR 19. Has benefited my setup greatly!! JRiver 19 upgrade purchase is a no-brainer.

[kstuart]

I have posted about this feature on an audiophile-friendly forum, and I think it should improve JRiver's reputation in those circles...

[audioriver]

Thanks a lot for this change, it does sound better on my system - not placebo! (hopefully)

[rayooo]

I've now installed MC19 on a second system, my primary (music room) player, and once again, I'm amazed how well the new-style play from memory works.
Quite honestly, I see no downside whatsoever.

As a test, I have a 24/192 version of Yes/Tales from Topographic oceans.  The longest track on that album is 21:38 and it's around 800MB in size on disk. (FLAC)
When loaded and playing, I see the MC19 memory usage increase by approx a full GB.  (playing smaller sized files, the memory usage seems to track as one would expect...I guess)

What I'm having a hard time understanding is, how can this track possibly load and play in a half second.
in effect, "CD" resolution tracks play "instantly"..others take a bit longer.. I just expected this long track would be more noticeable, it's really not.
It's a wired GIG-E to NAS, and it's an i7-4770S CPU, so reasonably fast system, but I'm still a bit confused actually.

[6233638]

Playback starts before the full track is loaded into memory. If you're seeing ~1GB of memory usage, the decoded audio is probably too big to fit into the amount of RAM MC19 allocates, as you are at the limit.

FLAC is really quick to decode though - it's only DSD tracks, and particularly DST compressed DSD tracks which seem to require a lot of CPU usage, taking as much as 20-30 seconds to fill the buffer on my system - which renders the computer unusable for ~20 seconds every time the track changes, and does not cache the full track any more, meaning that seeking can be impacted by disk I/O. This did not happen in MC18, because it always cached the entire file.

In practice, I see little difference between MC18 and MC19's behavior when playing CD quality tracks or high res PCM, other than increased memory usage (because it stores decoded audio rather than compressed audio) and a spike of CPU usage at the start of a track as it tries to fill the buffer as quickly as possible.