Jump to content


Why Kernel Streaming?

  • Please log in to reply
5 replies to this topic

#1 sirlordcomic



  • Members
  • PipPip
  • 73 posts

Posted 27 October 2013 - 07:38 AM

I'm curious what JPLAY devs take on Kernel Streaming is.


J. River does not recommend it. Given Matt's credentials, I put a lot of weight in what he has to say.







Edited by sirlordcomic, 27 October 2013 - 08:40 AM.

ControlPCCoolermaster Fortress FT03 i7 3930 @ 4gHz 16GB DD3 2133 RAM ASROCK Xtreme4-M Micro-ITX | PCI filter | NIC: Intel PRO PT dual-NIC (connects to LAN/WAN switch NAS/Internet & AudioPC (onboard Broadcom disabled) JRMC19 | JPLAY 5.1 | Windows 7 x64 | Synology NAS 411j (8TB) SHR + (3) 4TB SATA internal

AudioPC – Zotac ION Atom 1.6gHz | OriginAE M10 case | 4GB DDR3 1066 | Adnaco S3B w/ PPA mod (pending) | LPSU 12v/4-6A (pending) | Xtreme mode w/ Hibernate | Zodiac Gold w/ Voltikus linear PSU 

#2 modmix


    Die Hard

  • Members
  • PipPipPip
  • 114 posts

Posted 27 October 2013 - 09:30 AM

sirlordcomic said:

I'm curious what JPLAY devs take on Kernel Streaming is.

Good question /wp-content/forum-smileys/sf-smile.gif

Just a guess:

Compared to the regular "WaveOut method" in Microsoft Windows, kernel streaming requires less CPU time.
source: wiki


#3 Josef


    JPLAY team

  • Administrators
  • 3,311 posts

Posted 27 October 2013 - 03:24 PM

Kernel Streaming is lowest 'audio' layer in Windows: Why go through more layers (=WASAPI) if direct access is possible? In audio, less is usually more. (unlike WASAPI, ASIO _can_ be direct although it's not a given: there are 'ASIO' drivers out there which are using KS internally…) KS also allows for things that WASAPI does not: whereas both ASIO & WASAPI require memory copy operation per design, KS does not. Again, less is more. ASIO usually has _fixed_ Buffer size – it has been established from experience that various Buffer sizes can have sonic impact with smaller values sounding 'better' for most. Not being able to manipulate Buffer size is a clear restriction for ASIO. In addition, ASIO may require even more memory copy operations then WASAPI as it expects left & right channel to be 'separated' (WAV format has samples interleaved).   WASAPI allows for different Buffer sizes but requires certain 'minimal' size – Usually this is 192/256 samples for CD and 512+ for HiRez. One cannot go below that minimum. Kernel streaming, on the other had, has no such restrictions: one can even use Buffer of a single sample! ('DirectLink' as unique feature of JPLAY)   Hopefully this makes it clear now why we recommend KS: Lowest layer, no restrictions on Buffer size, zero-copy scenarios possible. Again, we believe 'less is more': not everyone agrees this makes a sonic difference and that is ok – but it does not change the facts :) Why JRiver (=Matt) does not recommend KS is something you will have to ask him: links you posted do not have a single reason mentioned.

Edited by Josef, 27 October 2013 - 04:30 PM.

#4 jrling



  • Members
  • 25 posts

Posted 30 November 2013 - 02:29 PM

Josef - your KS arguments are persuasive.   However I was puzzled about: 1. Zero Memory Copy - surely JPlay is all about copying memory - from the WAV file in RAM to the output buffer etc. How could this be done with 'zero memory copy'? 2. Single sample buffer - would that not cause intense CPU activity and interrupts and so 'noise' leading to worse SQ? Forgive my ignorance.

#5 Josef


    JPLAY team

  • Administrators
  • 3,311 posts

Posted 30 November 2013 - 04:09 PM

1. Not quite - That last step you mention (copy to output buffer) may be skipped with KS. (note what driver actually does is of course outside of application's control). 2. Smaller sample buffer increases CPU use, of course. But 'increase' does not neccesarily equal 'intense' and it may not have a relationship with interrupts either. Most people also prefer smaller buffer sonically so it would appear that things aren't as simple as 'reducing' CPU use :)

#6 jrling



  • Members
  • 25 posts

Posted 30 November 2013 - 05:35 PM

Thanks for prompt and helpful reply.

You never said a truer word than - 

so it would appear that things aren't as simple as 'reducing' CPU use

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users