Print

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

[JazzDoc]

Hi Matt

I followed your advice and went back to default settings. I already had buffering at 0.50 but reverted to 6 seconds for prebuffering. I removed the bta driver and installed the latest M2tech Hiface driver from the webiste (1.03.141)

Everything seems to work OK. No error messages saying that my hardware cannot play files higher than 16-Bit/44.1kHz.

The stuttering is still there if I can from one track to another 'on the fly' by double clicking another file name in my list of albums.

Here is a link to a short sample showing this:

The sample starts with a 16-Bit/44.1kHz track and then at arround 15 seconds I double click on another track by the same artist, this time a 24-Bit/192kHz file ripped from a DVD-A disc using DVD Audio Explorer. All other rips from my DVD-A discs using this software work fine. You may hear at the end that when I clikc the stop button the problem briefly corrects itself before playback stops (As you would expect it to do when you click 'Stop')

The link to download this example is:

http://hotfile.com/dl/66831334/61260f6/StutterFlac.flac.html

I recorded this using my Pioneer CD recorder. The recording is therefore, 16-Bit/44.1kHz and I have converted it to flac but it will give you an idea of what the problem sound slike.

Thanks

[Matt]

Any time you change sample rates, the playback engine will have to do a full reset of the audio device and you may hear a tick or similar.

The only way around this is to tell Media Center to resample everything to the same rate using DSP Studio > Output Format.

Do you only hear the issue when switching sample rates?

[Matt]

Oh my, the sample sounds terrible after the switch.  I hadn't listened to it yet when making the above post.

Just to rule out one thing for me, would you mind testing this build, and let me know if it does the same:
http://files.jriver.com/mediacenter/MediaCenter150106.exe

Then let's go from there based on the results.  Thanks.

[JazzDoc]

Thanks Matt. I installed 15.0.106 (I was previously running 15.0.95) but it didn't cure the problem. The stuttering sometimes occurs when changing between 16-Bit/44.1kHz files but it happens more frequently when I change between files with different sampling rates.

As an aside, I use a notebook PC and link it to the laptop used in my audio system to provide remote control access. I link the two computers using Windows Remote Desktop. The problem is worse when I am using the notebook to control the software on the laptop. The machines are linked through wireless technology. They are not hard wired into my home network so maybe this is the cause of the greater occurence of stuttering in remote mode.

I use a 1.5 TB Samsung USB drive to store my music files (http://www.ebuyer.com/product/167742) so maybe these mechanical drives lack the speed to cue up the files. SSD drives will probably be common place in a couple of years time but at present, they are too expensive and lack the capacity for use in my distributed system.

I am using MC with good equipment so I doubt that it is a fault with my DAC. I have the Naim DAC with Naim XPS Power Supply and the signal is fed into a Naim NAC52/Naim Supercap preamplifier and Naim NAP250 Power Amplifier. Speakers used are Naim SBLs.

This problem that I am having is an irritation more than anything else but it would be great if we could identify what is causing it and put it right. Keith at Purite Audio has promised me an M2Tech Evo for evaluation as soon as they have supplies. It will be interesting to see if I still get the problem with that.

Thanks again for your help

[Blue Boy]

I down loaded  your sample file and exactly the same thing happens to me every now and then, sometimes everything works perfect for many hour, and other times just for some album tracks
and then the stuttering begins, when stop and start playing it works again. 
I have another setup than Jazzdoctor, mine is:

Asus EEEbox
Musicstreamer USB - DAC where I added an selfpowered USB Hub to unload the computer.
Western digital HDD 1.5 TB

Everything is running under WASAPI, to be shure of my settings I have consulted Muscistreamers manufactor and they said it was the best setting for my DAC.


All my music is ripped with EAC to Wav. Files

I have tried to listen from memory instead of HDD, alter the buffert settings and many other things like uppsampling, but still the stuttering appears every now and then. IT IS VERY ANNOYING when it appears.


Thougt this could be useful to JMC to know, with my settings.

Kindly Blue Boy

[JazzDoc]

Sorry I forgot to mention this Matt ... The stuttering only happens when I run WASAPI. I don't get it when running ASIO or KS.

I want to keep with WASAPI as I prefer the sound. I find it is less 'hot' than other modes.

[Blue Boy]

I haven't tried any other settings than WASAPI but togheter with JazzDoc's example there maybe some
trouble with the WASAPI settings..........

[Blue Boy]

Yesterday I downloaded the latest build, and the stuttering still remains on Wasapi settings. It seems to appear by "itself" sometimes, but even worse if you jump from track to track while cuing songs.
I now have disabled the computers sound devices but this didn't change anything, it still stuttering.

This made me go for Kernel streaming, seems to work better, but don't know if there are any difference soundwise. This make me wondering, what is the difference between Wasapi and Kernel streaming as they both seems to be "audiophil" settings and works without windows mixer.

Maybe Jazzdoc have some input on the sound appereance ont this matter.....

Will there be any fix for the wasapi settings in the future?

Kindly Blue Boy

[JazzDoc]

I would not pretend to understand the technical difference between ASIO, KS and WASAPI Blue Boy. I know that WASAPI was developed by Microsoft and that some consider it better for this reason. I believe that all three options are 'bit perfect'

I have auditioned all three through my system and I did prefer the sound in WASAPI mode. It seemed more natural and open ... Less 'hot' if you prefer. There's not much in it but I do prefer WASAPI.

I will email the link to my stuttering audio recording to the technical guys at Naim Audio (I also copied in Keith at Purite Audio, the UK importers for M2Tech) and will post their reply here.

[Blue Boy]

Thank You Jazzdoc,

Do you use an ASUS computer, like I do? I'm asking because we seems to be the only one that have this issue with Wasapi, maybe the problem is the integration of Wasapi in ASUS computers..........Hmmm might be a long shot but everything should be considered......

[HiFiTubes]

Aren't we all having the same issue with "good" gear and WASAPI?

http://yabb.jriver.com/interact/index.php?topic=58949.0

I'm running a Zotac ION w/ Atom cpu.

My recent tests showed that "remove leading training silence" as an issue, but this same stuttering/sync loss creeps into my system now and then even with that setting disabled. I found that Mahavishnu Orchestra "Lost Trident Sessions" caused repeatable sync-loss/stuttering probably because they have quite a bit of silence at the beginning.

[HiFiTubes]

And good idea hosting that recording; that's exactly what happens to me which I have been calling a "loss of sync", stuttering is probably more accurate.

[Blue Boy]

Well, this is weird, we all have different equipment so a fail in our setups seems to be outruled.
Right now I running Kernel streaming, but with Kernel I can't use the upsampling feature...so I have to run it 44.100..........Let's hope our friends at JRiver can solve this issue with Wasapi

[JazzDoc]

Check your personal messages please Blue Boy

[JimH]

Everything seems to work OK. No error messages saying that my hardware cannot play files higher than 16-Bit/44.1kHz.

The stuttering is still there if I can from one track to another 'on the fly' by double clicking another file name in my list of albums.

The sample starts with a 16-Bit/44.1kHz track and then at arround 15 seconds I double click on another track by the same artist, this time a 24-Bit/192kHz file ripped from a DVD-A disc using DVD Audio Explorer. All other

Well, this is weird, we all have different equipment so a fail in our setups seems to be outruled.
Right now I running Kernel streaming, but with Kernel I can't use the upsampling feature...so I have to run it 44.100..........Let's hope our friends at JRiver can solve this issue with Wasapi

WASAPI gives the stream unmodified to the device.  A stutter may mean that the device driver can't handle the stream.

I had a problem last week with slight sound problems (irratic minor ticks) that turned out to be the Sony receiver.  It was unable to correctly play 192Khz files.

We found the problem by using MC to write the output to "Disk Writer" instead of WASAPI.  This records the exact output of MC.  Then we played it from disk at a lower bitrate.  It played correctly.  So we conluded tha the same stream (recorded to disk) could be played at 96 but not at 192Khz.

WASAPI itself is reliable.  The sound device may not be.

[Alex B]

Jim, a small correction if you don't mind: ...  played it from disk at a lower bitrate sample rate ...  

(please delete this reply if you fix it)

[HiFiTubes]

Well sumpthin funky is goin on for sure; DSP related overall.I'm sure it won't take look for our friend at JR to isolate and write this bug out of existence.

I've had this bug occur on three DACs. Imguessing 192kHz playback
is simply bringing some MS glitch to our attention.  I'll test a few more things tonight. 

[Alex B]

As an aside, I use a notebook PC and link it to the laptop used in my audio system to provide remote control access. I link the two computers using Windows Remote Desktop. The problem is worse when I am using the notebook to control the software on the laptop. The machines are linked through wireless technology. They are not hard wired into my home network so maybe this is the cause of the greater occurence of stuttering in remote mode.

Am I correct that MS Remote Desktop also tries to transmit the audio stream to the remote PC (or is the feature optional and disabled in your case) ? I am just wondering if it could interfere the WASAPI system anyhow.

However, as you didn't say that the problem exists only when you use Remote Desktop, also something else must be going on.

You could try UltraVNC for remote access. I works fine for me. I especially like the fact that I don't need to switch the Windows user to a remote user when I use it. The local display, keyboard & mouse remain available.

[Matt]

Thanks for the recording, and it's good to know this is the same artifact that HiFiTubes is describing when he says "loses sync."

I have heard this same artifact a couple times with WASAPI and a USB DAC.  In many months of listening, it has happened perhaps four times.

So I know that the problem is real.  I do not believe it's a problem in the core JRiver audio engine, because it is isolated to WASAPI (and maybe to USB DACs).  And from what I can tell, the JRiver audio engine is still delivering correct data when the problem occurs as the visualizations still look normal.

My operational theory is that the circle buffer used by WASAPI or perhaps the stock USB DAC driver can become corrupted due to some timing issue, and starts rolling over on itself.  If we could figure out how to reproduce the artifact more easily, we could search for a workaround.  From reports, it seems like it's more likely to occur at times when it might take a little extra time to fill a WASAPI buffer (like when a new track is starting).  It may turn out that the solution is as simple as never filling the buffer to 100%, or never filling more than 50% in a single pass, or some other silly thing like that.

I'm out this week, but will take a hard look at this when I'm back.  If people have tips for how to reproduce the issue, I would appreciate it.  Also, if you've ever had it occur on something other than a USB DAC, please let me know (be sure to listen to the sample clip first to make sure it's the same issue).  Finally, if anyone that can easily reproduce this would be able to work with me testing different ideas once I'm back, let me know.

Thanks.

[Blue Boy]

Hello Matt,

Well it seems to me that there are various brands and type oc DAC's that have this problem, I post the specs for my DAC that is connected via USB cable to my computer. As I said earlier, the manufactor said it would perform at the best with Wasapi and in  my case with an external selfpowered USB hub. Don't know if you need this info to solve it, but here you go...I will also send a link to the manufactor of my DAC so they can listen to JazzDocs soundfile, then we see what info they can provide.


Specification Music Streamer II+

Electrical Full Scale output 2.25 Volts RMS
Frequency Response (20 Hz/20 kHz) 0 dB/ -1.4 dB
Noise Floor (DC to 30 kHz) 20 uV RMS
S/N Ratio (DC to 30 kHz) 101 dB
THD+N (1 kHz FS 44.1 kS/s) 0.008%
USB to Audio output isolation > 20M Ohm
Interface
Data Rate up to 96 kS/s
Bit Depth up to 24 bit
Transfer Protocol asynchronous
USB type 1.1 or above
Power Requirements (USB buss) 350 mA

[JazzDoc]

Thanks Matt and Blue Boy.

Thanks for your commitment to resolving this problem Matt. I still regard it as an irritation rather than something that makes MC unusable. I don't think there can be a hardware problem as WASAPI worked fine when I was using Foobar2000/Dark One 2.1. Having said that, I really like the interface of MC and would rather live with that than change back to Foobar2000. I don not imply any criticism of Foobar or its users. It's a great piece of software. The preference is a purely personal thing.

[mb1]

Stutter occurs in only with buffering message. Every 5 minutes of playing. If I make  a tag change, while playing, then stutter makes playing impossible. Any similar activity in MC has the same impact. Playing from memory makes system unplayable with stutter.
Using 24 bit with 48 hz with WASAPI.  Buffer settings at lowest settings. Increasing  buffers makes stutter worse.
System has external DAC linked by SPDIF, forte sound card. Win 7 64 bit. Nothing I watch in system resources is busy. CPU, threads etc are all at low utilization levels.
This problem came back in .104 or 105. It was gone in the 2 or 3 dot MC releases before that. Yes Foobar has no problems.

[HiFiTubes]

It's true this problem does not exist in Foobar, unless you manually add the stock plugin to Remove Silence.

My guess is that this feature is enabled by default in MC?

I have had this issue with (2) USB DACs, and (1) external DAC connected via AES/EBU cable (not USB) to my Lynx AES16-E.

I will host some files that present this problem shortly.

[HiFiTubes]

It would help if folks with this problem could post their playback settings. Are you using gapped, cross-fade, gapless?

I tested out Gapped 2 second and it resulted in LOUD static filled playback on the track that previously caused the stuttering when using remove silence option.

Looking at the waveform, there is complete silence on the left channel for about 10 seconds, until the intro on the right channel is brought on the left.

Everything I'm seeing points to silence being an issue with WASAPI. For example, gapless and crossfade seem to minimize the chance (though not 100%) that stuttering or corrupt playback will occur, whereas gapped and often buffering cause problems.

I didn't have time to edit and post a sample .flac but if anyone has track 2 of the Lost Trident Sessions, this is the track in question, and manually advancing from track 1 > 2 with gapped 2 second results in loud static.

Also of note is the new Gapped Fade has a hiccup on my system where you here a blurb off the last track (after faded out), prior to playback of the next track; I didn't check it with ASIO yet though.

[Blue Boy]

I have used gapless and remove silence, standard buffering size tried different settings and tried to
use different USB port nothing helps. The funny thing is that everytime I did a change a let the system
play with my ampfliers volume very low, then it can works for hours, next time the problem starts after only a couple of tracks, the I stop playing and start again just to hear the stuttering again. I have asked the manufactor about both Wasapi and Kernel Streaming the answer is Wasapi is the way to go
before Kernel. Right now I use Kernel as I'm growing tired to not be secure if Wasapi works for more that ten tracks.

This is my first experience of "computer listening" and my first software so I have not a clue about
how other software works, but since it works great in Foobar it should be working for JRM I think.

If I could wish for one thing it would be a version of MC 15 to be for music only in audiophil version without all added things for TV YouTube DVD and so on, for me less is more when it comes to music.
add ons

[HiFiTubes]

I have used gapless and remove silence, standard buffering size tried different settings and tried to
use different USB port nothing helps. The funny thing is that everytime I did a change a let the system
play with my ampfliers volume very low, then it can works for hours, next time the problem starts after only a couple of tracks, the I stop playing and start again just to hear the stuttering again. I have asked the manufactor about both Wasapi and Kernel Streaming the answer is Wasapi is the way to go
before Kernel. Right now I use Kernel as I'm growing tired to not be secure if Wasapi works for more that ten tracks.

This is my first experience of "computer listening" and my first software so I have not a clue about
how other software works, but since it works great in Foobar it should be working for JRM I think.

If I could wish for one thing it would be a version of MC 15 to be for music only in audiophil version without all added things for TV YouTube DVD and so on, for me less is more when it comes to music.
add ons

Don't worry, there is enough critical mass here, and it will get sorted out I'm sure. We're obviously all experiencing the same wonkiness, and no doubt it's due to the brilliant folks at MC doing something the right way, clashing with the "Windows 7 way".

[HiFiTubes]

WASAPI itself is reliable.  The sound device may not be.

Well, the problem is the devices are pretty well designed as far as I know:


BSS FDS 366T digital crossover
Lynx two B sound card
Lynx AES16 sound card
Zodiac+ external DAC
Naim external DAC
Music streamer DAC

I'm hopeful it will get sorted out and I hope some of you can test some more with various playback settings. If I can host that file with the silence on left channel, I'll post the sample here.

[Blue Boy]

I'm shure it will be sorted out, I googled a lot of software before i decided to go with JRiver and  don't regret it, I also have an understanding that there is a big variety of both DAC's and computers out there, and to have MC15 to work perfect for all us users must be a BIG challenge. So that's why I go for Kernel til' this problem i solved.

But as a user of computer for many years I don't understand that so many software has so many applications, If I developed software I would start with a basic version and then sell plugins to the
user who needed them, or if I put it this way I only use MS Office to write  letters, still I have powerpoint, excel and o lot of other things that is complete useless for me.....but thats me, to each his own.....It would be great to have a dedicated audiophil software for just music. I think that JR MC have come close to be THE ONE software.

[nedam]

This stutter happened to me (It sounded exactly like the stutterflac file.) and I have no idea if these settings will help or if they are settings you would like to use but I changed my Wasapi settings to:

Device- I changed from Default to my device (M-Audio Revolution)
Open device for exclusive access is checked
Flush device buffers on startup is checked
Flush device buffers on pause is checked
Present 24-bit data in a 32-bit package is checked
The Buffering is set to .50 seconds

As I said I have no idea if this will help and I have not had the time to play with the settings to see how the are affecting the sound quality but I have not had that stutter since. This stutter started for me after 101 but I cannot say it started immediately after the upgrade.

Edit- I should have mentioned that the stutter started after I had been listening to music for a while (An hour or two) without the stutter and would happen maybe 25% of the time after it did start.

Nedam

[Visth]

Made an account just to report this issue.

I am experiencing the exact same problem. Top-notch media PC. Different hardware setup from what i have read in this thread, but this is not hardware related. Windows 7 - 64 bit.

Erratic and unpredictable bug, hard to trouble shoot. Never happens immediately, usually after playing somewhere between 15-20 minutes, sometimes a little longer. Now, I use DirectSound and not WASAPI...

I did notice network issues when this problem occurs. I can not access the media server using iphone xpremote for instance. remote desktop into media PC also stalls. it is as if the PC "hangs" but there are no error messages. It gets "unstuck" after varying unpredictable intervals and plays as if the song has forwarded normally, it skips in time. Sample rate of songs varies some but it is not predictable which song will do it, or what bit rate will do it.

Not sure if these extra comments help, but right now MC is unusable for any prolonged periods of time...

[JohnT]

Hey guys,

Matt the playback guru is on vacation at the moment, but I'm sure he'll be able to get this sorted out when he gets back next week.

Thanks!

[HiFiTubes]

Erratic and unpredictable bug, hard to trouble shoot.

Very true, my best setting is 6 seconds pre-buffering, with .5 playback buffer, WASAPI, 1second Agressive crossfade, one sample rate (96kHz), and even then the bug will creep in every now and then.

That said, I did post info that points to a possible repeatable bug but that is using Standard Gapped transition with manual track advance to a song with some silence at the start.

I learned that pre-buffering loads the next song in the playlist as soon as the current one is "loaded" for playback; what happens if a user often jumps around to play items not in the current playlist; I would think this would bypass pre-buffering completely, meaning that the playback buffer is the sole layer of protection against a data shortfall.

My experience is the bug occurred with MUCH more frequency as I manually selected songs not in a current playlist for playback (not using Add As Next or Add to Playing Now) as opposed to letting MC "sit" and run through a playlist.

[HiFiTubes]

Hey guys,

Matt the playback guru is on vacation at the moment, but I'm sure he'll be able to get this sorted out when he gets back next week.

Thanks!

Hopefully Matt's floating in a canoe right now w/ no Internet access  .

[JazzDoc]

My experience is the bug occurred with MUCH more frequency as I manually selected songs not in a current playlist for playback (not using Add As Next or Add to Playing Now) as opposed to letting MC "sit" and run through a playlist.

I've found that to be the case as well. I set pre-buffering to 6 seconds although Matt advised me to reset to default value. Either way, I still got the stuttering

[Matt]

I have more information, but no solution yet, on this issue.

I made the WASAPI output plugin write to disk _exactly_ the same audio data as it delivers to the USB DAC.  The audio data being delivered to the device is correct, because with the USB DAC stuttering, the file on disk is still correct.

Secondly, I believe the nature of the problem is out-of-order buffers in the USB DAC driver or WASAPI itself.  When the stuttering starts, any change to the playback data (like using the 'Tone' testing tool in Room Correction) is heard as a series of stutters.  So while you would expect to hear:
music, music, music, tone, tone, tone, tone, etc.

You instead hear:
music, tone, music, tone, music, tone, tone, etc.

I believe either WASAPI or the USB DAC driver use some sort of circling buffer pool, and they are losing their order.

Like I said, we don't have a solution yet.  I'll post here as we learn more.

[Blue Boy]

Hi Matt,

Since we are a lot of users with the same problem, with both different computers and DAC's it
seems to me, that both USB and DAC's are rouled out as the problem? Just my five cents.....

Blue Boy

[Matt]

Please test using this build (this build is NOT RECOMMENDED for general consumption):
http://files.jriver.com/mediacenter/test/MediaCenter150108.exe

It switches to event-driven WASAPI buffer filling.

Please note that the changes are not fully vetted.  This build is only to test if event-driven buffer filling cures the stuttering issue.

Thanks for any help.

[Blue Boy]

Okey I will try this out, and let you know tommorow (it is soon midnight in my country) what the outcome is.

[Visth]

it is for sure a buffering issue and has little to do with the WASPI. If you set a gap (0.5 seconds is enough) and no crossover, it will drastically reduce the problem. In fact, i tested this hypothesis by setting up two zones with two different settings. one zone plays better now that it is set to 0.5 gap, and the 4S cross over (this actually does not even work, since there is no crossover audible) will eventually cause this problem to reoccur.

Still, quickly changing songs will do it, and also letting things play for a while will elicit the problem again. The surest way to go back to normal play for a while is acutally restarting my HTPC and it will be good for a bit. I have no USB DAC's, rather two internal sound cards and I use DirectSound. I suspect something is going drastically wrong with the buffers and somehow they stack, and stack until they are full. Forced pauses will reduce the problem. Someone else in this thread also figured out that setting flush buffers upon pause etc will help. I think we are all on to the same thing. However, I do want to stress this happens in DirectSound just the same, and has nothing to do with USB.

[Matt]

it is for sure a buffering issue and has little to do with the WASPI. If you set a gap (0.5 seconds is enough) and no crossover, it will drastically reduce the problem. In fact, i tested this hypothesis by setting up two zones with two different settings. one zone plays better now that it is set to 0.5 gap, and the 4S cross over (this actually does not even work, since there is no crossover audible) will eventually cause this problem to reoccur.

Still, quickly changing songs will do it, and also letting things play for a while will elicit the problem again. The surest way to go back to normal play for a while is acutally restarting my HTPC and it will be good for a bit. I have no USB DAC's, rather two internal sound cards and I use DirectSound. I suspect something is going drastically wrong with the buffers and somehow they stack, and stack until they are full. Forced pauses will reduce the problem. Someone else in this thread also figured out that setting flush buffers upon pause etc will help. I think we are all on to the same thing. However, I do want to stress this happens in DirectSound just the same, and has nothing to do with USB.

I believe you might have a different problem (technically, not audibly) than some of the others, although you might try build 108 above with WASAPI and report your results.

Thanks.

[HiFiTubes]

WASAPI crashes .108 (emailing log).

W/ gapped 2 second or Crossfade Aggressive 1 second does as well.

ASIO on .108 works fine.

[JazzDoc]

Thanks for your ongoing commitment to resolving this problem Matt. I will try Build108 and report back

[JazzDoc]

Just installed Build 108. It seems to playback OK in ASIO, KS and WASAPI (I haven't had the crash that you experienced HiFiTubes0

I then moved from one track to another and one album to another without stopping playback first. I did this using a range of albums with differing resolutions. I haven't had any stuttering yet.

I will continue to use Build 108 and will try to make it stutter. Controlling the application remotely from my Samsung netbook using Windows Remote Desktop has always greater instance of the stuttering problem.

Have to do some work now (Haven't reached the age at which I can become a fully paid up member of the 'gentleman of leisure' club) but I will continue to experiment and report back to this forum

Thanks Matt

[JazzDoc]

A couple of hours later and I still haven't experienced any stuttering. This is starting to look good! (Hope I haven't spoken too soon)

I've continued to move between tracks and albums without stopping playabck and between files of differing bitrate and sample rate. I've even controlled the application from my netbook using Windows Remote Desktop and it still works fine. I even let my external USB drive containing my digital music files go into hibernate mode and it still started up again without stuttering.

I still need a few more days before I would confirm that the problem is solved but as I said, this is looking good.

[HiFiTubes]

I think Matt's on the right track. I reported to him, after disabling all 'flush' options that I was able to introduce a more subtle stutter (more like when an ASIO buffer is set too low) after about 5 minutes of manually advancing through tracks with 2 second Gapped and WASAPI.

But the big news...I just tested my EMU 0202 at work with this build, and the "unable to stop playback" bug with this device using WASAPI is GONE.

I tried two PCs and it would hard lock MC down on both to where I could often not even reboot, but had to hard power down.

I'm going to listen at work all day on this USB DAC with this build; will try on my Lynx system again tonight.

[Blue Boy]

I have downloaded the new build, it worked for a while just playing an album, then i switched for some tunes like cuing for some seconds and played another album, this time it just stops in the midle of a song and a "noice" like stuttering a thousand times faster appears. Before it was like the song continued playing with stuttering but now it hangs on a fixed point. I played with wasapi, and standard settings that is recomended.

Blue Boy

[Matt]

Please test this build (again, NOT RECOMMENDED for general consumption):
http://files.jriver.com/mediacenter/test/MediaCenter150110.exe

Pick new audio output 'Windows Audio Session API (WASAPI) [event style]'.  You might experiment with different buffer sizes, including 'Minimum hardware size' as that may be the most direct.

Thanks for any feedback.  I'll post in a few minutes with more information about event style WASAPI.

[Matt]

Media Center 15.0.110 (and later) add a new audio output: Windows Audio Session API (WASAPI) [event style]

This output plugin uses WASAPI interfaces, but features many notable changes from the previous WASAPI implementation:

• It let's the audio subsystem pull data (when events are set) instead of pushing data to the system.  This allows lower latency buffer sizes, and removes (hopefully) the unreliable Microsoft layer documented in this thread.
• It creates, uses, and destroys all WASAPI interfaces from a single thread.
• The main 'pull loop' uses a lock-free circle buffer (a neat system we built for ASIO), meaning fullfilling a pull request is as fast as possible.
• The hardware (or WASAPI interface) never see any pause or flush calls.  Instead, on pause or flush, silence is delivered in the pull loop.  This removes the need for hacks for cards that circle their buffers on pause, flush, etc. (ATI HDMI, etc.).

Feedback welcome.  Thanks.

[JazzDoc]

Loaded up Build 110 Matt. I installed it over the top of Build 108 as I don't know if uninstalling a previous version also deletes my settings and all the links to my artwork.

Build 110 really doesn't work for me at all:

With Windows Audio Session API (WASAPI) [event style] as the selected output and 'Minimum hardware size' selected I get a very fast stuttering on a playback, regardless of resolution

With Windows Audio Session API (WASAPI) [event style] as the selected output and 0.50 (Recommended) selected it will playback but once again, the stuttering is present. When I try to change from one album to another or between tracks on a single album (Including 'Next' and 'Previous') Build 110 hangs and I have to select the 'Stop' button to resume playback.

Not a good experience with Build 110 so I've gone back to Build 108. Once again, it seems to be working fine.

[Blue Boy]

My computer has locked itself so hard that I can't even use ctrl alt delete to shut the system down.
Noticed tgis from earlier builds but in those cases it took some times for the computer to give acces.
But now it just don't work without a "hard" crash. I´m still on 108.