Memory Play & WASAPI Options

[sjc]

This is my first post to the fb2k forum and I've just recently started using fb2K and I had two questions about general operation.

I was under the impression that fb2k has a memory play feature that loads files into RAM prior to playback. Is this a default feature or is it an option that needs to be activated for use? I couldn't seem to find any settings for this.

I've read several posts about the WASAPI mode that allows exclusive mode control of sound card resources and bypasses the Windows mixer (please excuse me if I am not using the correct terminology). I downloaded the WASAPI component from the fb2k official components list on the fb2k website but as cautioned in the Wiki information it didn't seem to work well and I lost the frequency spectrum visualization, etc. In my case I do use an external USB DAC and was hoping to be able to feed various bit depth and sample rate files to the DAC directly for processing and not have the bit depth/sample rate set by the sound card. Any suggestions or comments on this subject are greatly appreciated.

Thank you in advance for any replies.

[adam777]

Hi sjc,
As for playing from RAM - go to "file->preferences->advanced->playback" and set "full file buffering up to" to whatever maximum file size you wish to be buffered completely to RAM.
Regarding WASAPI, make sure you activated it under "file-preferences->playback->output". Once that is done, as far as I know WASAPI, if working correclty passes the audio as is to the output device you set, in your case your USB DAC, so you should be able to feed various bit depths/sample rates to your DAC, as long as it supports those formats as input.
If you try to pass an unsupported format you should receive an error message.
Adam.

[Peter]

The "full file buffering" option should be more correctly named "break gapless playback for large files".

[mudlord]

I was under the impression that fb2k has a memory play feature that loads files into RAM prior to playback. Is this a default feature or is it an option that needs to be activated for use? I couldn't seem to find any settings for this.

why do you want to load the entire file to RAM?
*trollface*

[melosoares]

sjc,

foobar has some wasapi playback issues with some asynchronous USB DACs

read this, it may help you:

http://www.hydrogenaudio.org/forums/index....showtopic=92299

[GeSomeone]

The "full file buffering" option should be more correctly named "break gapless playback for large files".

I noticed that "side effect" too , the trick is to have a reasonable max. value. It will, among others, depend on how fast the computer and/or disc is.

[jaro1]

I read in this or some other recent topics Peter's comments related to wasapi output plugin (buffer under 50ms, etc...). I'm a little bit disappointed he didn't mention nothing about pull mode support (wavert) rather than doing some usb buffer patchwork on the existing component.I admit, that further buffer decrease without pull mode support doesn't make sense, but i still don't understand the reason not to support pull mode if supported by the driver, as there are reliability benefits. Maybe there are some unknown problems. The buffer length in the output preferences could be fb2k own software buffer reserve used for decoding or dsp processing and wouldn't be related to potential wasapi output component buffer size setting (hardware).
Peter please, express yourself to lack of wavert support, thanks.

This post has been edited by jaro1: Jan 2 2012, 18:53

[Peter]

Next time the component gets updated, all known compatibility issues will be addressed. That includes pull mode support, whatever that is good for.

[jaro1]

Perfect news, thank you very much Peter for considering. I'm sure many fb2k users on WV/7 will benefit from that update.
Some specific parts of this article with short sample code could be usefull.

This post has been edited by jaro1: Jan 2 2012, 23:21

[Brod]

why do you want to load the entire file to RAM?

Why not? Reduces the number of HDD reads.

This post has been edited by Brod: Jan 3 2012, 08:42

[Peter]

why do you want to load the entire file to RAM?

Why not? Reduces the number of HDD reads.

How so? It has to read the exact same amount of data from the hard drive.

[j_b]

Why not? Reduces the number of HDD reads.

Actually, reading the entire audio file into memory may result in more HDD reads and writes. Most likely, Windows will have to page out blocks of address space to make room for the incoming audio file. What’s more, unless the process doing the memory allocation explicitly locks it, there is nothing to stop Windows from swapping pages of the audio file in and out as it sees fit. Note: Windows limits the amount of memory that can be locked to a small percentage of total real memory space.

This post has been edited by j_b: Jan 3 2012, 15:04

[Brod]

Sorry, didn't explain properly. Of course it does the same amount of reading, but it does it all in <1 second, which is nice if you're using the HDD for other applications.

I don't believe that the data would be paged out, at least not on my system. I have 8GB of RAM and I never use more than 30%.

This post has been edited by Brod: Jan 3 2012, 21:28

[A_Man_Eating_Duc...]

So if you skip through a few songs in a row you will be hammering the disk and hurt the performance of those applications?

If your that worried about disk performance all your music would be on a different disk to your applications anyhow.

[Brod]

So if you skip through a few songs in a row you will be hammering the disk and hurt the performance of those applications?

You're grasping at straws here...

If your that worried about disk performance all your music would be on a different disk to your applications anyhow.

Why would I buy another HDD when my current setup and settings already gives me perfect playback?

[A_Man_Eating_Duc...]

I'm grasping at the same straws you are

[Peter]

Windows cache already does a pretty solid job at scheduling hard disk access, so an app performing reads at the rate required for music playback should not be a burden to the other apps running on your system. Additionally, if you run "verify file integrity" or alike on your playlist before playing, there's a solid chance that no physical hard disk access will occur during playback of these files.

[GeSomeone]

.. if you run "verify file integrity" or alike on your playlist before playing ..

I see your point, but to me that sounds even worse than using a reasonable size "full file buffer".
By the time all HDD will be replaced by SSD (if ever) we can forget about this option.

[Seeking_Lossless]

I think i already asked this (full file buffering) question before. According to one of super mod here, it have no benefit to playback quality. There are many audio site / forum out there believe in such myth. Read here:
http://www.hydrogenaudio.org/forums/index....mp;#entry727274

I read in this or some other recent topics Peter's comments related to wasapi output plugin (buffer under 50ms, etc...). I'm a little bit disappointed he didn't mention nothing about pull mode support (wavert) rather than doing some usb buffer patchwork on the existing component.I admit, that further buffer decrease without pull mode support doesn't make sense, but i still don't understand the reason not to support pull mode if supported by the driver, as there are reliability benefits. Maybe there are some unknown problems. The buffer length in the output preferences could be fb2k own software buffer reserve used for decoding or dsp processing and wouldn't be related to potential wasapi output component buffer size setting (hardware).
Peter please, express yourself to lack of wavert support, thanks.

Please don't push Peter like that. He already did good job maintaning foobar2000 and official components since many years ago. You realize that he probably do all of this without incentive and pretty much consume his time, do you?

This post has been edited by db1989: Jan 4 2012, 16:34

Reason for edit: Please edit rather than double-posting so soon; merged.

[jaro1]

To Seeking_Lossless:
If general impression of my comment is such you've described or understood, than i'm sorry about that as it wasn't meant that way. That bad feeling from it could be caused because of taken my comment out of context as it was a little bit offtopic here.
I know i was maybe annoying with all my comments related to WaveRT support as i've asked about it also in other threads, but all i wanted was firstly to write my feature request and secondly to know Peters opinion about it if not accepted, what isn't against the rules. That doesn't mean absurd command to push Peter to do immediately my requirement, of course. Feature request can or doesn't have to be accepted and i doubt Peter will do something without to be sure its good for something just because it costs time, exactly as you wrote.

This post has been edited by jaro1: Jan 4 2012, 17:39

[Brod]

I'm grasping at the same straws you are

How so?

On default settings web browsing can cause my music to stutter. When I load entire songs into RAM it doesn't.

Seems pretty simple to me.

This post has been edited by Brod: Jan 5 2012, 05:36

[washu]

How so?

On default settings web browsing can cause my music to stutter. When I load entire songs into RAM it doesn't.

Seems pretty simple to me.

If browsing the web causes your music to stutter then something is likely very wrong with your PC. Loading songs into RAM is just masking whatever issue(s) your PC has.

[A_Man_Eating_Duc...]

Maybe the realtime stuttering is from a bad driver or something, a NIC or Wireless card?

Have you used DPC Latency Checker to see if you can pin point the problem?

According to the W7 resource monitor on my system.

Playing a 320 MP3 = 40,000 B/sec
Playing a FLAC = 160,000 B/sec

No recent hard drive should struggle to stream that amount of data.

[Brod]

There is nothing wrong with my PC.

Can't tell if you actually care about the RAM feature or if you're just being argumentative. Not biting, sorry.

This post has been edited by Brod: Jan 5 2012, 10:17

[nesf]

There is nothing wrong with my PC.

Don't just assume that. Your PC could run fine in every other way but have skipping and stuttering audio due to a bad driver somewhere making bad calls to the CPU. DPC Latency checker will find if this is the case for you. I've had this happen to me with a USB chipset driver for instance. It only takes a few minutes to check, so it's well worth doing.