INTERACT FORUM
More => Old Versions => Media Center 15 (Development Ended) => Topic started by: JazzDoc on September 03, 2010, 05:11:31 pm
-
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
-
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?
-
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.
-
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
-
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
-
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.
-
I haven't tried any other settings than WASAPI but togheter with JazzDoc's example there maybe some
trouble with the WASAPI settings..........
-
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
-
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.
-
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......
-
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.
-
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.
-
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
-
Check your personal messages please Blue Boy
-
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.
-
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)
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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
-
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".
-
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.
-
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.
-
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
-
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...
-
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!
-
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.
-
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 ;D.
-
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
-
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.
-
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
-
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.
-
Okey I will try this out, and let you know tommorow (it is soon midnight in my country) what the outcome is.
-
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.
-
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.
-
WASAPI crashes .108 (emailing log).
W/ gapped 2 second or Crossfade Aggressive 1 second does as well.
ASIO on .108 works fine.
-
Thanks for your ongoing commitment to resolving this problem Matt. I will try Build108 and report back
-
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
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
The playback stall issue is fixed with this build:
http://files.jriver.com/mediacenter/test/MediaCenter150111.exe
We believe the 'Windows Audio Session API (WASAPI) [event style]' is now ready for general release, and would appreciate testing.
I'm especially interested if this solves the original out-of-order-buffer issue documented in this thread.
You may need to experiment with buffer sizes using event style WASAPI. If you hear hiccups, try a larger buffer size. Some buffer sizes may cause playback to be silent or fail.
Also, some hardware (like my internal motherboard sound card) simply do not support event style WASAPI.
Thanks for any testing.
-
I downloaded 110 and realy try to "stress" it with jumping from track to track, played Albums for a few minutes and then jump to next album let that album play for some hours then start jumping again between tracks, it works without "stutter" ;D
But when "cuing" a song with the "timebar" it stops. Have to shut down MC and start again.
Is it just me or has the sound been altered aswell? To me it seems to lack in details, when I made
comparings with earlier versions to my CD player it was absolute equal in sound, When making a A-B comparing with my CD player with the latest build I hear a difference and at least to me there is some brillians lost in the 110 build. Not a big difference but still............I have used the recommended buffert settings.
But another thing that has chanced I couldn't play with any other settings than 44,100 in the upsampling "tab" now that issue is gone, and I have tried the settings uppsampling to 48 000
works fine with my equipment.
When will this version be stable? Is there anything to do with the sound? Should I make a "clean install instead of the uppgrade version?
-
it works without "stutter" ;D
Good.
But when "cuing" a song with the "timebar" it stops. Have to shut down MC and start again.
Please install 111 above for a fix.
Install point releases (i.e. all builds of v15) over the top using 'Express' in the installer.
-
Thank you, I will download 111, but what about my question about the sound? Do you have anything
on that issue? Is there anyone else experienced the same that I did?
-
.111 w/ EMU 0202 WASAPI [event style]
Gapped Standard 2 seconds: no problem yet, but MC doesn't use a gap - tried 2 and 4 seconds and often get instant, almost gapless playback (tried toggling remove silence). Use gapless for sequential is off.
Gapped Fade: blurb of faded track "reappears" for split secod after fade, and prior to start of next track
Crossfade Aggressive 1 second: no stuttering but this is definitely causing MC the most buffering but it's not real "smooth" - sometimes it won't even load the next track but will skip to another (6 second prebuffering w/ remove silence disabled). EDIT - works much smoother with remove silence enabled.
buffer = 100ms
.111 w/ EMU 0202 WASAPI
Can't stop playback (was fixed with .08 I think)
.111 w/ Lynx AES16-E WASAPI [event style]
report to follow
Can't comment on audio quality yet until further listening.
-
I'm looking forward to your report on the Audio...........
-
Thanks for the testing everyone.
There will be no audio quality difference between the WASAPI methods since they both deliver the same data to the card. I would look elsewhere (DSP, phase of the moon, etc.) if the two methods sound different.
Instead, this change is about providing a WASAPI solution that works well on as wide of a range of hardware as possible. The initial tests look good for the event-based WASAPI with regards to improving the USB DAC experience.
I've been a little amazed at how differently each piece of hardware reacts to different modes, settings, etc. I'll write a little more about this once the dust settles.
Thanks again.
-
.111 w/ EMU 0202 WASAPI
Can't stop playback (was fixed with .08 I think)
I think the EMU will require event style WASAPI. Build 108 _only_ had event style WASAPI (it was before we forked to two outputs).
With non-event style WASAPI, the card dead-locks in a way that we have not seen from any other hardware. I'm not sure it's even worth chasing if the event style works well.
This sort of compliments my point that different WASAPI methodologies will work better with different hardware, and it's a good thing that we now support both major WASAPI data flow methods.
-
For your infomation, my 110 build has now running without problem for 12 hours non stop and there
is no problem with stutter anymore. Tommorow I will download 111. My version of MC feels very stable.
Thank you for all answers.
Blue Boy
-
No problem's yet on the AES16-E to Zodiac+ w/ .111 after 4 hours.
It just sounds real darn good.
default of 50ms led to some breakups (like ASIO buffer drops = crackles), so I'm using 100ms for testing.
-
I'm very happy to hear the event-style WASAPI is working without degrading into stutter with USB DACs.
It's been working well for me too including usage as the renderer for HDTV (which didn't work with the old WASAPI on this USB DAC).
Thanks for all the help on this one.
-
I loaded Build 111 last night and used it for a couple of hours without problems. Playback is free of stutter and I was able to move from one track to another and one album to another without stopping playback. I am running default settings. I finished by setting playback to shuffle mode and this caused no problems with seamless and fast transition between tracks. I did not experience the stutter and playback hang that I got with Build 110 at all.
Looks like Build 111 is good!
Thanks Matt
-
No problems last night; so I left it overnight to play. Maybe hit a corrupt file? My system, is set at resample all to 96kHz.
Gene Ammons sounded extra special.
-
No problems last night; so I left it overnight to play. Maybe hit a corrupt file?
That's a file problem. It's some URL that uses a Directshow filter (that crashed) for decoding. If you look just before the log snippet you posted, you should see the filename.
Please start a new thread to chase the problem with the file, as this thread is already long.
Thanks.
-
Sounds good. Maybe it was something trying to use DC-Bass source.
-
So for those of us where both WASAPI mode works, what is the recommended default? "Normal" or "Event Mode"?
-
111 works perfect. No problem anymore now this software runs like a dream!!!
-
Hi, I found that simply moving a mouse over the track list in Standard (or 3D) views often causes stuttering of playback in my Win 7 64bit / HiFace driver 1.0.3.140/ JRMC15 build 159 with WASAPI Event Style.
To illustrate this, I recorded a video using iPhone that can be accessed thru the URL:
http://www.youtube.com/watch?v=eyhVAkB8vKQ
The quality of the video and sound is poor but the stuttering is quite audilble (after some 15 seconds).
I did not have to click anything, it is just moving the mouse that causes this. I move it quite fast in the video but it can be observed also at slower moves.
The hardware buffer was 50msec, using longer times seems improve the situation but stuttering also might be heard. I also have observed similar beaviour using KS.
This seems strange that moving mouse has anything to do with audio...
-
Wow,
I've been suffering this issue with MC14 and earlier MC15 releases.
As my netbook is limited to 100Mbits networking capabilities, I always thought this was due to some buffer filling issue.
Now it has vanished with Event Style, even though sometimes the music stops, but I think this is due to the limited network bandwith with this computer (never happened with a Gbits capable one).
Cool feature !
TontonGuigui
-
The WASAPI Event Style is indeed a big progress and I even thought for a moment this was finally what I was looking for. But after having played a bit with this mode, issues still can be found.
I am just playing from my laptop harddisk - no computer network in my setup. Have not observed the stutter in Direct Sound mode.
-
Here's a Hi-face thread:
http://yabb.jriver.com/interact/index.php?topic=56403.0
Please copy and paste your post to that thread and then post your System Info from MC Help.
-
The WASAPI Event Style is indeed a big progress and I even thought for a moment this was finally what I was looking for. But after having played a bit with this mode, issues still can be found.
I am just playing from my laptop harddisk - no computer network in my setup. Have not observed the stutter in Direct Sound mode.
Run PCI Latency Checker (http://www.thesycon.de/deu/latency_check.shtml), then start playback, then disable your wi-fi adapter completely in Device Manager, keep watching DPC Checker. Maybe try other devices.