Print

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

[Padawan38]

Hello

I'm using JRiver 18 on a PC with 2 drives, SSD for system and software applications and HDD for music storage.
I was listening music using a playlist with the samples directly pulled from the HDD to the playlist.
I was not satisfied with the sound, dropouts and overall bad listening experience.

But then I tried to build my playlist by putting the samples on the SDD, this drasticly changed the deal, much much better.

So question:
Would it be possible for the next JRiver release to manage 2 or more drives, and to automatically built the playlist on the specified drive (the better one), in order to prevent manual user setup (actually what I did to put some samples on the SDD) ?
In other words to automatically (dynamic) manage a playlist on a specified drive.

FYI, the Aurender streamer (1 SDD + 1 HDD) is doing this automatically (transparent for user).

Hope I've been clear.

Thank you for your feedback

Rgds

[6233638]

I think Tools > Options > Audio > Settings: Play files from memory instead of disk (not zone-specific) does what you want. (better than - it uses RAM rather than your SSD)

[Padawan38]

Hello

I disagree as I used this setup as well when I was using the HDD.

[6233638]

If it was already playing back from memory, it seems that the problem lies elsewhere. RAM can access data at speeds measured in gigabytes per second, and even the best SATA3 SSDs will max out around 500MB/s.

What are you using for audio output mode? It seems like the buffer size may not be large enough.

[Padawan38]

I use Kernel Streaming.
BTW I have remarked whatever the buffer setup (in seconds), the memory allocation does not change, it's strange in my mind, any idea ? ...

FYI the Aurender (my "model") has 4Gb RAM but instead of basically charge the music from the HDD to the RAM it first stores the playlist from the HDD to the SDD and then play the music (I don't have found details on the RAM usage btw).
I know part of the reason for doing this is that it make sleep the HDD because of magnetic issues.

[6233638]

Sorry, you keep bringing up this Aurender player - are you playing audio through your PC, or streaming to it?

If you're playing on the PC (which is what Kernel Streaming implies) what you want to change is the buffering option under "output mode settings".
I think the "prebuffering" option only affects streaming to your PC from a network, and not local playback. (it sounds like that is the option you were changing)

You did not mention what operating system you are using, but it would be better to use WASAPI Event Style (or WASAPI) rather than Kernel Streaming if you are using Windows Vista/7/8.

[Padawan38]

I use a PC for music storage and player and then a DAC, I don't own an Aurender but I'm interested in its architecture which is excellent to me.
Why WASAPI ? ... it's known as using Windows features which is less good as Kernel, no ?  

About the memory management, I though that using "Play files from memory instead of disk" setup would increase the memory % buffer allocation but seems it does not change anything neither the other setup meant to store an amount of seconds. Maybe some setup are only for streaming as you said.

[6233638]

Why WASAPI ? ... it's known as using Windows features which is less good as Kernel, no ?  

WASAPI is typically the best output from a PC - kernel streaming is not nearly as good. I would try using that before adjusting buffer sizes. The other high quality option is ASIO, but that typically requires extra drivers to be installed.

About the memory management, I though that using "Play files from memory instead of disk" setup would increase the memory % buffer allocation but seems it does not change anything neither the other setup meant to store an amount of seconds.

I've just done a little testing, and it seems to store the entire track in memory. With nothing playing MC18 seems to be using between 15-30MB of RAM. As soon as I start playing anything, that changes to the track's filesize, plus 60MB. So if I play a 140MB DSF file, memory usage is about 200MB. If I play an 890MB FLAC file, it's about 950MB.

That's interesting though, because it suggests to me that it is still decoding during playback, rather than decoding and storing the decoded uncompressed PCM audio in memory. (I wonder if the additional memory used during playback is that prebuffer size)

[JimH]

WASAPI is typically the best output from a PC

WASAPI Event Style is preferred over WASAPI.

If available ASIO (but not ASIO4all) would be the best choice.

http://wiki.jriver.com/index.php/Audio_Output_Modes

[6233638]

WASAPI Event Style is preferred over WASAPI.

Yes, you're right. When I said WASAPI, I meant WASAPI generally; I should have been more clear that Event Style was preferred over "regular" WASAPI.

If available ASIO (but not ASIO4all) would be the best choice.

Ah - I was thinking ASIO included ASIO4all, which seemed unnecessary now with WASAPI Event Style.

I suppose if your hardware has a specific ASIO driver, that is probably better than WASAPI Event - though could you explain why that is? Lower latency?

[mwillems]

Yes, you're right. When I said WASAPI, I meant WASAPI generally; I should have been more clear that Event Style was preferred over "regular" WASAPI.
Ah - I was thinking ASIO included ASIO4all, which seemed unnecessary now with WASAPI Event Style.

I suppose if your hardware has a specific ASIO driver, that is probably better than WASAPI Event - though could you explain why that is? Lower latency?

One reason that true ASIO is better (at least with my soundcard) is that it allows JRiver to reset the card's sample rate.  Asus Xonar cards (and many other PC soundcards, like some of the creative and M-Audio cards) automatically resample everything to their control panel output rate setting when using WASAPI (or any other mode), but in ASIO (and only in ASIO), they allow software to automatically change the sample rate output of the card.  ASIO is also much lower latency (for me) than WASAPI. 

ASIO4All is just a software wrapper around kernel streaming as I understand it, so it has all the problems kernel streaming has (plus some extras of its own).  The only reason I ever use ASIO4ALL is to trick JRiver into recognizing my USB turntable input as an ASIO line in, but its even a little flaky for that purpose, so I often wind up using Audacity with loopback when I want to listen to a record through JRiver.

[6233638]

One reason that true ASIO is better (at least with my soundcard) is that it allows JRiver to reset the card's sample rate.  Asus Xonar cards (and many other PC soundcards, like some of the creative and M-Audio cards) automatically resample everything to their control panel output rate setting when using WASAPI (or any other mode), but in ASIO (and only in ASIO), they allow software to automatically change the sample rate output of the card.  ASIO is also much lower latency (for me) than WASAPI. 

Ah I see - I was under the impression that WASAPI took over the sound card in the same way, but it seems that only applies with some devices. Thanks for the explanation.

[kstuart]

mwillems wrote: "ASIO4All is just a software wrapper around kernel streaming as I understand it, so it has all the problems kernel streaming has (plus some extras of its own). "

I use ASIO4ALL 2.11 Beta1 (which AFAIK is the final version) with MC18, and it works brilliantly, with no problems.  In my system, it works better than WASAPI or other output modes (but I make no claims about anyone else's system).

I also find that ASIO4ALL works significantly better with MC18 than with other software players.

[JimH]

kstuart,
I've removed part of your post.  We've discussed this before.   I don't want misinformation to be spread on our forums.  mwillems' statement is correct.

[kstuart]

" WASAPI is just a Microsoft wrapper on Kernel Streaming."

Why are these sort of generalizations, considered to be a worthwhile response to a specific situation ?

[JimH]

" WASAPI is just a Microsoft wrapper on Kernel Streaming."

I think you mean ASIO4All, not WASAPI.

Why are these sort of generalizations, considered to be a worthwhile response to a specific situation ?

As originally stated, it is correct.  ASIO4All is a wrapper around Kernel Streaming.

[kstuart]

and WASAPI is a Microsoft wrapper around kernel streaming.   And so what ?

It doesn't say anything about any particular situation.

[JimH]

and WASAPI is a Microsoft wrapper around kernel streaming.   

That's not correct.  WASAPI and Kernel Streaming are two different interfaces.

http://en.wikipedia.org/wiki/WASAPI#Audio_stack_architecture