INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: weird "heartbeat" sound on HD (especially 24/192) files with AudioEngine D1  (Read 9641 times)

pablolie

  • Recent member
  • *
  • Posts: 10

i love the sound of regular 16/44 files on this setup. perfection through my trusty Grado RS-1.

but has anyone else experience weird little pops while playing 24/192 files? i have gone through every setup option, but prolly missed something, i guess. it really makes listening to such files a very UN-enjoyable experience. anyone else experienced this? yes, i am playing everything bypassing every windows (7) driver.
Logged

fauxfreshness

  • Recent member
  • *
  • Posts: 30

Can you up the buffer on your ASIO config panel for your device?  I don't know about a "heartbeat" sound, but popping is pretty common when there's high latency.  This can be much worse with USB 3.0 on some hardware, or if the outboard DAC/Amp requires more amperage than the port can deliver.  I went to an auxiliary USB 3.0 card that uses SATA power ports on my PC to make sure it can supply enough amperage, along with a fairly overpowered (800w) PSU for the system.  USB is kind of a "best effort" protocol and connection bus, and needs the CPU to do...anything.  :-)  It isn't like IEEE 1394 with dedicated processing, so if the CPU is tied up, that can make it worse.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

There's some weirdness and inaccuracies in the response from fauxfreshness, but yes, this does sound like a problem with the size of the Audio Buffer.

It is probably too small.  But, some devices also freak out a bit when the buffer is too large.  Try tweaking the buffer settings under Options > Audio > Device Settings.

If you want to know more about what this setting impacts, I explained it here:
http://yabb.jriver.com/interact/index.php?topic=92423.msg636378#msg636378

To be perfectly clear, though... All audio applications on a computer must write to an audio buffer of some kind.  That's how you make sounds. You write them to the audio buffer, and then the audio driver makes the sound device output it.  This setting controls the size of this buffer.

It is unlikely to have anything to do with the USB port's power (which won't be used by basically any professional audio device that has a separate power supply).  It could have to do with crappy third-party USB3 implementations on early motherboards before Intel built USB3 into their chipset, conceivably, but again, this doesn't relate to power in any way (but to crappy USB3 implementations with crappy drivers).  But this is pretty unlikely.  I'd only pursue that if changing the buffering settings (and/or updating the driver for your DAC) doesn't help.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

fauxfreshness

  • Recent member
  • *
  • Posts: 30

Actually, not weird nor inaccurate at all.  While at Microsoft, we frequently had issues we were testing with USB attached hardware.  I was a field engineer that covered performance monitoring and optimization for server and desktop platforms.

I have a Native Instruments KA6 I/O interface that's bus powered, and his device was bus powered from what I saw of it here:

http://audioengineusa.com/Store/D1-24-Bit-DAC

And yes, Native Instruments and other hardware vendors have had quite a few issues with unstable power, to the point where inline ammeters for USB device draw are becoming recommended when used with real time processing demands paired to lazy commit hardware (like hard drives).
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5234
  • "Linux Merit Badge" Recipient

It is unlikely to have anything to do with the USB port's power (which won't be used by basically any professional audio device that has a separate power supply).  It could have to do with crappy third-party USB3 implementations on early motherboards before Intel built USB3 into their chipset, conceivably, but again, this doesn't relate to power in any way (but to crappy USB3 implementations with crappy drivers).  But this is pretty unlikely.  I'd only pursue that if changing the buffering settings (and/or updating the driver for your DAC) doesn't help.

Glynor, your buffering advice is excellent, but I respectfully disagree with the above quoted part of your post.

A fair proportion of consumer USB DACs (probably a majority) are USB powered, meaning that they have no external power supply.  As fauxfreshness suggested, OP's Audioengine DAC (http://www.amazon.com/Audioengine-D1-24-bit-Digital-to-Analog-Converter/dp/B006IPH5H2) is one such DAC, it draws power directly from the USB port.  I agree with you that the issue may not be a power shortfall, but it is (in my opinion) probably related to the fact that the DAC is USB-powered.

Modern USB3 implementations (with modern drivers) still have problems with noise that can affect DACs, especially DACs that draw power from the USB port.  I've seen several forum members experience these kinds of issues, and I have personally gotten loud interference or pops when connecting a USB-powered DAC directly to a USB3 port on a modern Intel NUC model (the model started shipping early this year).  The artifacts in question were improved by plugging the DAC into an extender cable, or eliminated by plugging it into a powered USB hub (suggesting it was partly localized interference, but also partly noise-on-power-related, but not a "low power" issue or the extender wouldn't have produced a positive effect).  

This is not particularly surprising because the same USB ports also completely borked any kind of bluetooth receiver plugged directly into them, which is a more widely acknowledged problem with USB3 (check out intel's forums for a litany of complaints about the NUCs with bluetooth keyboards). Intel even wrote a white paper on that issue http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb3-frequency-interference-paper.html, and I don't think the underlying issues have been fully resolved (or at least haven't been resolved with intel's drivers and hardware).  Obviously RF interference is not the same as audio band interference, but equipment that doesn't have good isolation can still get goofed up by it.

I used to think a USB port was a USB port, full stop, but I am no longer convinced that is true.  Not all USB3 port/DAC combinations exhibit problems, but some do, and if someone told me they were getting interference or pops on a USB-powered DAC, my first piece of advice (after buffering, on which your advice is very good) would be to try a different USB port or a powered USB hub.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Fair enough. I did say "professional" but even then, you're right. I have a Scarlett that is USB powered (for the record, though, it works fine on every crazy laptop I've thrown at it).

My guess is that those that don't work well, are pushed way too close to the edge of the USB spec and should have aux power.  They probably don't for marketing not engineering reasons.

USB3 implementations have been a bag of hurt for some time, and I didn't completely discount that option. Still, buffering is much more likely to be the cause.  Sometimes too much info is worse than too little with follow up, you know?
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Actually, not weird nor inaccurate at all.

As I said, you were mostly right.  However, since you're going to call it out, this was inaccurate and/or weird:

but popping is pretty common when there's high latency.

Popping and clicks on a DAC are typically due to buffer overruns, caused by the buffer being too small, not too large.  The smaller the buffer, the lower the latency, so that would be an issue with LOW latency playback situations, not high-latency playback situations.  It is true that occasionally the reverse is true with certain temperamental DAC implementations, but it is the far less common case, and it really seemed from your entire comment that you'd mixed up what causes high and low latency in the playback chain.

It is possible that you just explained quickly/poorly, but that was the first thing I noticed that was "weird" in your comment.

Furthermore...

USB is kind of a "best effort" protocol and connection bus, and needs the CPU to do...anything.  :-)  It isn't like IEEE 1394 with dedicated processing, so if the CPU is tied up, that can make it worse.

This is ancient information that will not die.  Yes, the driver stack for USB is implemented in software and the driver stack for old IEEE 1394 was (partially) implemented in hardware, so back when 133MHz bus speeds and single-core Pentium 3 and PowerPC G3 CPUs were common, the USB driver stack could be performance limiting.  Particularly if you were trying to push low-latency video (from a webcam) over the bus or other things that take up a ton of the available bandwidth.

But even back then, there were a bunch of problems with USB implementations that people attributed to this software overhead which really weren't anything of the sort, but which had much more to do with the shared bus (and that most USB implementations only had two actual ports on the internal hub) and the northbridge/southbridge bus (which was shared with the NIC and the AGP port and all sorts of other things).

With any currently supported system now, however, unless what you are doing is pegging the CPU completely (in which case, the problems may be simply too much work for too few resources), the overhead from USB implementations is a rounding error.

It might impact achievable latencies, but not substantially, and latency isn't important at these scales in this application.  The difference between a 50ms buffer and a 100ms buffer doesn't make any substantial difference for things MC will be used for in general practice.

None of that should be interpreted to suggest that there aren't crappy USB interface implementations out there (the 3rd Party USB3 ones for Intel boards before Ivy Bridge were absolutely awful, and AMDs are cruddy too).  And, of course, there are a TON of extremely crappily designed USB devices out there, with equally cruddy drivers.

But the fact that anyone out there can put out crappy hardware with slipshod drivers and slap a USB port on it does not mean that the "reason" is is performing poorly is because your modern Core i5 CPU is "too utilized" to use USB properly when it is running at idle.  Because, when playing back audio, it is probably running at idle, and half-asleep.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

To the OP:

Try tweaking the Buffer settings as I explained above.  The rest above is probably noise not relevant to your situation.  If changing the buffering settings doesn't work, then I agree that trying other solutions would be warranted.

But, until we have further confirmation that it isn't just a buffer setting, though, this remains the by-far most likely cause.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5234
  • "Linux Merit Badge" Recipient

Fair enough. I did say "professional" but even then, you're right. I have a Scarlett that is USB powered (for the record, though, it works fine on every crazy laptop I've thrown at it).

My guess is that those that don't work well, are pushed way too close to the edge of the USB spec and should have aux power.  They probably don't for marketing not engineering reasons.

I think you're probably right, also I've run into some "DIY" style USB powered DACs (i.e. made by small producers from FOSS or readily available designs), and those have been pretty flaky in the noise isolation department.

Quote
USB3 implementations have been a bag of hurt for some time, and I didn't completely discount that option. Still, buffering is much more likely to be the cause.  Sometimes too much info is worse than too little with follow up, you know?

I agree.  I give it an 90% chance his problem is buffer related, especially since it's linked to a change in sample rate.  Sorry to muddy the water  ;D
Logged

pablolie

  • Recent member
  • *
  • Posts: 10

Oddly enough, I don't encounter the problem when playing the exact same file through Windows Media Player (which can be made to play FLAC files).

I have played with the buffer sizes to no avail - they file sounds exactly the same, with weird low popping noises.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Bummer.

The next step, I'd say, is to examine other possible causes with the DAC.  It does seem to be a temperamental one (though perhaps devices with those kinds of specs just are temperamental).  In any case, this is from them:
http://audioenginefiles.com/pdfs/Whitepaper.pdf
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Oddly enough, I don't encounter the problem when playing the exact same file through Windows Media Player (which can be made to play FLAC files).

That's not odd at all, and is expected.

Windows Media Player does not use the same audio path as MC.  In fact, I'm fairly certain Windows Media Player does not support WASAPI Exclusive playback.  This means that no matter the source format, the audio coming out of your computer is not 24-bit/192kHz, but is whatever you have Windows set to in the Sound Control Panel, and it is routing through the Windows mixer.  So, those fancy FLAC files you have aren't playing the same way in WiMP.

This is why the Whitepaper I linked to above said exactly this about WASAPI playback.  It sounds like, to me, their WASAPI support is a bit flaky.  But, like I said, I don't know, perhaps this kind of device is just temperamental that way?

In any case, read the thing from the manufacturer.  If you want to, also describe your settings in MC in detail under Tools > Options > Audio and we can tell you if you're doing anything crazy.  We'd want to know about everything enabled or disabled or set in:

Tools > Options > Audio > Audio Device (including under Device settings)
DSP Settings enabled, including Output Format
Everything under Tools > Options > Audio > Settings
Everything under Tools > Options > Audio > Volume

Screenshots would be a good way to provide the detail.

And post the contents of the System Information tool under Tree > Services & Plugins > Reporter > Copy to Clipboard (paste it into a Text file, save it, and then attach the text file to your post).
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

pablolie

  • Recent member
  • *
  • Posts: 10

thanks Glynor! here it goes, attached screenshots and here's the sys info dump...

Library
    Total files: 40193
    Audio files: 34649
    Image files: 5477
    Video files: 59
    Other files: 8
Processing
    Thumbnails built: 16% (6486 of 40193)
    Audio analyzed: 0% (10 of 34708)
Background Tools Running
    No tools currently running
Power
    Playback (disable automatic sleep)
Media Center
    Version: 20.0.21.0 Registered
    Install path: C:\Program Files (x86)\J River\Media Center 20\
    Interface plug-ins: Interface Plugins: TiVo Server (not running)
    JRMark: never run
    Memory used: 160 MB memory
    Handles used: 332 handles
Advanced System Info
    Memory & CPU
        CPU features: MMX, SSE2, SSE3, SSSE3, SSE4.1
        Free Physical Memory: 4.2 GB
        Total Memory: 7.9 GB
    Operating System
        Microsoft Windows 7 64-bit
    Batteries
        Microsoft Composite Battery (driver 6.1.7600.16385)
    Computer
        ACPI x64-based PC (driver 6.1.7600.16385)
    Disk drives
        INTEL SSDSA2CW120G3 ATA Device (driver 6.1.7600.16385)
        WDC WD20EADS-00R6B0 ATA Device (driver 6.1.7600.16385)
    Display adapters
        NVIDIA GeForce GT 440  (driver 9.18.13.4052)
    DVD/CD-ROM drives
        PIONEER BD-RW   BDR-203 ATA Device (driver 6.1.7601.17514)
    Human Interface Devices
        HID-compliant consumer control device (driver 6.1.7600.16385)
        HID-compliant consumer control device (driver 6.1.7600.16385)
        HID-compliant consumer control device (driver 6.1.7600.16385)
        HID-compliant device (driver 6.1.7601.18199)
        HID-compliant device (driver 6.1.7601.18199)
        USB Input Device (driver 6.1.7601.18199)
        USB Input Device (driver 6.1.7601.18199)
        USB Input Device (driver 6.1.7601.18199)
        USB Input Device (driver 6.1.7601.18199)
        USB Input Device (driver 6.1.7601.18199)
        USB Input Device (driver 6.1.7601.18199)
    IDE ATA/ATAPI controllers
        ATA Channel 0 (driver 6.1.7601.18231)
        ATA Channel 0 (driver 6.1.7601.18231)
        ATA Channel 1 (driver 6.1.7601.18231)
        ATA Channel 1 (driver 6.1.7601.18231)
        ATA Channel 2 (driver 6.1.7601.18231)
        ATA Channel 3 (driver 6.1.7601.18231)
        ATA Channel 4 (driver 6.1.7601.18231)
        ATA Channel 5 (driver 6.1.7601.18231)
        Intel(R) 5 Series/3400 Series Chipset Family 6 Port SATA AHCI Controller - 3B22 (driver 7.0.0.1013)
        Standard Dual Channel PCI IDE Controller (driver 6.1.7601.18231)
    Imaging devices
        EPSON Perfection 4490 (driver 3.2.4.1)
        Logitech HD Pro Webcam C910 (driver 13.51.823.0)
    Keyboards
        HID Keyboard Device (driver 6.1.7601.17514)
    Mice and other pointing devices
        HID-compliant mouse (driver 6.1.7600.16385)
    Monitors
        NEC MultiSync EA274WMi(Digital) (driver 1.13.807.1620)
    Network adapters
        Intel(R) 82578DC Gigabit Network Connection (driver 11.16.87.0)
        VMware Virtual Ethernet Adapter for VMnet1 (driver 4.2.1.0)
        VMware Virtual Ethernet Adapter for VMnet8 (driver 4.2.1.0)
    Ports (COM & LPT)
        Communications Port (COM1) (driver 6.1.7600.16385)
    Processors
        Intel(R) Core(TM) i5 CPU         661  @ 3.33GHz (driver 6.1.7600.16385)
        Intel(R) Core(TM) i5 CPU         661  @ 3.33GHz (driver 6.1.7600.16385)
        Intel(R) Core(TM) i5 CPU         661  @ 3.33GHz (driver 6.1.7600.16385)
        Intel(R) Core(TM) i5 CPU         661  @ 3.33GHz (driver 6.1.7600.16385)
    Sound, video and game controllers
        Audioengine D1 (driver 6.1.7601.18208)
        HD Pro Webcam C910 (driver 13.51.823.0)
        NVIDIA High Definition Audio (driver 1.3.30.1)
        NVIDIA High Definition Audio (driver 1.3.30.1)
        NVIDIA High Definition Audio (driver 1.3.30.1)
        NVIDIA High Definition Audio (driver 1.3.30.1)
        Realtek High Definition Audio (driver 6.0.1.6602)
        Shure Digital    (driver 6.1.7601.18208)
    Storage volume shadow copies
        Generic volume shadow copy (driver 6.1.7600.16385)
    System devices
        ACPI Fixed Feature Button (driver 6.1.7601.17514)
        ACPI Power Button (driver 6.1.7601.17514)
        Composite Bus Enumerator (driver 6.1.7601.17514)
        Direct memory access controller (driver 6.1.7601.17514)
        File as Volume Driver (driver 6.1.7600.16385)
        High Definition Audio Controller (driver 6.1.7601.17514)
        High Definition Audio Controller (driver 6.1.7601.17514)
        High precision event timer (driver 6.1.7601.17514)
        Intel(R) 82801 PCI Bridge - 244E (driver 6.1.7601.17514)
        Intel(R) H55 Express Chipset LPC Interface Controller - 3B06 (driver 6.1.7601.17514)
        Intel(R) Management Engine Interface
        Intel(R) Management Engine Interface (driver 1.0.0.0)
        Intel(R) PCH SMBus Controller - 3B30 (Intel(R) SMBus 2.0 Driver) (driver 6.8.1.2)
        Intel(R) processor DRAM Controller - 0040 (driver 6.1.7601.17514)
        Intel(R) processor PCI Express Root Port - 0041 (driver 6.1.7601.17514)
        Microsoft ACPI-Compliant System (driver 6.1.7601.17514)
        Microsoft System Management BIOS Driver (driver 6.1.7601.17514)
        Microsoft Virtual Drive Enumerator Driver (driver 6.1.7601.17514)
        Motherboard resources (driver 6.1.7601.17514)
        Motherboard resources (driver 6.1.7601.17514)
        Motherboard resources (driver 6.1.7601.17514)
        Numeric data processor (driver 6.1.7601.17514)
        PCI bus (driver 6.1.7601.17514)
        Plug and Play Software Device Enumerator (driver 6.1.7601.17514)
        Programmable interrupt controller (driver 6.1.7601.17514)
        System board (driver 6.1.7601.17514)
        System board (driver 6.1.7601.17514)
        System board (driver 6.1.7601.17514)
        System CMOS/real time clock (driver 6.1.7601.17514)
        System speaker (driver 6.1.7601.17514)
        System timer (driver 6.1.7601.17514)
        Terminal Server Keyboard Driver (driver 6.1.7601.17514)
        Terminal Server Mouse Driver (driver 6.1.7601.17514)
        UMBus Enumerator (driver 6.1.7601.17514)
        UMBus Root Bus Enumerator (driver 6.1.7601.17514)
        VMware VMCI Host Device (driver 9.5.10.0)
        Volume Manager (driver 6.1.7601.17514)
    Universal Serial Bus controllers
        Generic USB Hub (driver 6.1.7601.18328)
        Generic USB Hub (driver 6.1.7601.18328)
        Generic USB Hub (driver 6.1.7601.18328)
        Generic USB Hub (driver 6.1.7601.18328)
        Generic USB Hub (driver 6.1.7601.18328)
        Intel(R) 5 Series/3400 Series Chipset Family USB Enhanced Host Controller - 3B3C (driver 9.1.1.1020)
        Intel(R) 5 Series/3400 Series Chipset Family USB Enhanced Host Controller - 3B34 (driver 9.1.1.1020)
        Logitech USB Camera (HD Pro Webcam C910) (driver 13.51.823.0)
        USB Composite Device (driver 6.1.7601.18328)
        USB Composite Device (driver 6.1.7601.18328)
        USB Composite Device (driver 6.1.7601.18328)
        USB Root Hub (driver 6.1.7601.18328)
        USB Root Hub (driver 6.1.7601.18328)
        VMware USB Device (driver 4.1.0.2)

Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Okay, looking at the screenshots and the system info dump, here are a few things I'd try.

First: Read the Whitepaper I linked above.  They give a bunch of specific recommendations for this exact issue.  To be clear, that whole PDF is about this exact issue, from your device manufacturer, linked in the FAQ for that device.  Clearly, it is something of a common issue with their DAC for whatever reason.

Further, looking at their guide, and your system info dump, a few things stand out immediately.

1. You do not have your Intel Chipset Drivers installed!  The version on your system is from June 2006!  These are the drivers used for your DAC!
http://wiki.jriver.com/index.php/Troubleshooting_Drivers#Platform_Drivers

2. You do not have your Intel SATA Drivers installed!  The version of the Intel ATA Drivers on your system for this driver is also from June 2006!  You need to install the Intel Rapid Store drivers.
http://wiki.jriver.com/index.php/Troubleshooting_Drivers#Storage_Drivers

Those two things should be addressed before anything else.  Also, I didn't look in detail, and it won't be relevant to this issue, but since those drivers are so old (they've basically never been updated, some of them appear to be the ones that shipped with Windows 7 RTM), you probably should check your GPU drivers as well.

Then, assuming it isn't fixed, moving on to possible causes within MC.

However, before I list the rest, to be clear: Do this stuff from here on out one at a time.  Test.  See if there is any difference.  If that fails, revert the change (with the exception of a few things you might want to keep, noted below) and then move on and do the next thing.  Do not apply them all or apply them all willy-nilly.  If you do, even if you "solve" it, you'll never know what the problem was, or if you've enabled unnecessary things.

1. Options > Audio > Audio Device > Device Settings > Buffering: As I said before, this is the most likely fix.  This is further confirmed with what your DAC manufacturer said in their PDF guide for this exact issue.  Try them all, one at a time.  The PDF said that lower values were likely (but not always) better.  Make sure you tried all of them from Min - 100ms at least, and then one of the high ones (300 or 400).

2. Options > Audio > Settings > Prebuffering: This is less likely to have an impact, but is easy to test.  Prebuffering controls the amount of the file that is "read ahead" by MC during playback.  Increasing pre-buffering times can improve reliability of playback when the source media is too slow or otherwise unreliable.  This would not seem to be the case here, except that you said it happens more often with 24/192 files which would be larger in size and so require higher performing disk.  So, worth trying to increase this and see what happens.

3. Options > Audio > Settings > Play silence at startup: Try with this enabled.  This typically helps with pops and clicks when playback starts or stops, but is worth testing.

4. Options > Audio > Audio Device > Device Settings > Disable event style: This puts WASAPI support into legacy mode (which uses a push method rather than raising events to send audio commands to the device).  This is typically required for older hardware with older drivers.  However, it is worth trying.  I don't know for sure which mode that DAC prefers.

5. DSP > Output Format: You don't have this DSP configured and you should.  The Output Format DSP does not change audio files from bitperfect unless you tell it to or it needs to.  It increases compatibility with files you otherwise could not play (because they have the incorrect number of source channels, are too high or low of Sample Rate, and other things like that).  But it does not touch things it does not have to touch, and passes those through "clean".  Make sure resampling is set to match what your DAC can handle natively (so they aren't resampled needlessly), and set the Channels stuff correctly and to your preference, and enable it.

This is unlikely to help but you should do it anyway.

6. Options > Audio > Volume:  This is also very unlikely to help with this issue, but you should do it anyway.  Read: http://wiki.jriver.com/index.php/Volume
You probably want Internal Volume or Disabled Volume (if you use the volume knob on your DAC exclusively), especially since you have Maximize device volume during playback enabled.  MC's Internal Volume is possibly better than the knob, and almost certainly not inferior.  Also, the Loudness feature is awesome.

Okay, that's it from MC's Options.  If none of that helps, it probably isn't MC.  On to weirder and harder to diagnose stuff.  Looking back at the PDF from the DAC manufacturer, two other things stand out immediately in your System Info dump.  You have two other possibly meddlesome USB devices attached.  Both exact examples aren't particularly poorly behaved, however, they are classes of products that often cause trouble, and it looks like from the PDF that the Audioengine is sensitive to stuff like that on the USB bus.

So, try with each of these items physically removed from the system:

* Logitech C910 Webcam
* Shure USB Audio Device: I don't know specifically what this is, but it is another USB Audio device and could be interfering or need new drivers.

If those don't help, then try:

* Realtek Onboard Audio: You can also try updating the drivers for the Realtek onboard audio device (which are also ancient).  Instead, if it isn't used and you can figure out how, go into your motherboard's BIOS and just disable it entirely.

* It looks like you do have newer Intel Network drivers installed there, somehow, but you might want to double-check that.

* If you're totally at a loss, uninstall vmware and try.  It could be a conflict with one of the system services or drivers that vmware installs.  I've seen weird things from old, outdated copies of vmware myself.

Then, I'd start trying the more esoteric fixes suggested in their PDF, including the trying different USB ports and a powered hub, and the other stuff in their guide.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

pablolie

  • Recent member
  • *
  • Posts: 10

i will just reply to one  point - no one should install drivers that have not been approved by micrososft's validation process. my drivers are totally up to date when it comes to that - and i have made bad experiences every other way. i would urge users to stay away from unapproved upgrades. i had the intel drivers for SSD and they were a mess. no thanks.

i will pay close heed to reading the white paper and the other advice.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

i will just reply to one  point - no one should install drivers that have not been approved by micrososft's validation process. my drivers are totally up to date when it comes to that - and i have made bad experiences every other way. i would urge users to stay away from unapproved upgrades. i had the intel drivers for SSD and they were a mess. no thanks.

I have no idea what the heck you are talking about here.  Intel's latest drivers are WHQL certified and signed.  Your drivers are absolutely not up to date.

If you somehow believe that the only source for certified drivers are those provided through Windows Update, you were given some very bad information.  Windows Update's drivers strive to provide only very basic functionality for most hardware.  In fact, often the drivers provided in the Windows Catalog or through Windows Update are extremely old (and at work, we often find them to be incredibly buggy).  The ones provided through Windows Update are designed to provide the most basic functionality with the smallest footprint.

The recommendation from Microsoft themselves is absolutely to obtain drivers from the device manufacturer if your system is not working properly.  Intel's chipset drivers are typically very high quality, and the current set was released way back in March 2014, and WHQL certified in June.  So, if they were terribly broken because of some bug, we would have certainly heard about it by now.

Bad and buggy drivers can sometimes cause issues.  Updating to the latest-and-greatest, unsigned, Graphics driver, for example, isn't always a great idea (though it might be needed because they often also fix plenty of bugs).  And little botique companies certainly have issues regularly.

But this is Intel, not a botique vendor, and you're having a problem.  Make a Restore Point if you're worried about it.  You can always roll back if needed.

As far as your comment about Intel's SSD, I'm not sure what you're talking about at all, since SSDs don't have drivers (the storage controller does, and yours is quite old, but the SSD itself does not have any drivers that you need to install in Windows).  You may have had a botched firmware update (like the one Intel had a few years ago that reduced some drives to 8MB capacity).  But that's firmware, not drivers, and is an entirely different thing.

Updating firmware is sometimes required, but is always a risky proposition, and should only be done when required and when you know there's a decent chance it will solve the problem (based on listed issues from the vendor).

You can do whatever you want, of course, but I would certainly guess this is (by far) the most likely possible solution to your problem, if simply tweaking the Buffer setting didn't work.  That's why I put it first.  It is glaring.  Especially since we know the drivers on the system are (much) older than the chipset and CPU in your system itself.  The H55 chipset on your computer was launched in Q1 2010.  Your drivers are from 2006.  If you won't at least try this modest and reasonable advice, then I won't be able to assist further.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

you were wrong.

Really?

* Realtek Onboard Audio: You can also try updating the drivers for the Realtek onboard audio device (which are also ancient).  Instead, if it isn't used and you can figure out how, go into your motherboard's BIOS and just disable it entirely.

A more appropriate response would have been:

"Hey, man, thanks for all your efforts.  I didn't want to update my drivers unless I had to because I've had bad experiences with that before, but I tried some of the other things, and this worked!  Thanks!"

Good day.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

pablolie

  • Recent member
  • *
  • Posts: 10


"Hey, man, thanks for all your efforts.  I didn't want to update my drivers unless I had to because I've had bad experiences with that before, but I tried some of the other things, and this worked!  Thanks!"


Indeed it would have been. My apologies for sounding abrupt.

Thanks for your diligent help, which indeed resulted in my being able to address and solve the issue. Truly appreciated.

Again - my tone was off and I regret that considering you invested significant time in replying and helping me out.

Have a great weekend...p

Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

I, too, apologize if I came off as an arrogant jerk.  That was not my intent.  Tone is often very hard to determine when reading the written word in a forum.  I try to always give people the benefit of the doubt, though I fail at that too sometimes.  In this particular instance, I would describe my intent as "excited" and "enthusiastic" (and a bit frustrated) but not angry in any way.

I'm very glad you got it sorted out.  Those Realtek onboard audio devices are often a menace.  This thread will hopefully help someone else solve a similar issue in the future.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

Fex

  • World Citizen
  • ***
  • Posts: 115
Re: weird "heartbeat" sound on HD (especially 24/192) files with AudioEngine D1
« Reply #19 on: September 01, 2015, 12:51:23 pm »

...This thread will hopefully help someone else solve a similar issue in the future...

glynor

thanks for your time and the very detailed hints here. This helped me to solve my problem. Cool!
Logged
Pages: [1]   Go Up