palmfish
Headphoneus Supremus
During the time that I owned my HD600, i found the paint and build quality to be very good. In this regard, I believe they are superior the the HD800.
During the time that I owned my HD600, i found the paint and build quality to be very good. In this regard, I believe they are superior the the HD800.
really? my HD800's are very well made. maybe you got a counterfeit? -- there was some guy posting that his vinyl was cracking on his 800's. the 800's are more like a mercedes than the beemer 320 hd600's -- so, what's happening with yours? are they falling apart?
really? my HD800's are very well made. maybe you got a counterfeit? -- there was some guy posting that his vinyl was cracking on his 800's. the 800's are more like a mercedes than the beemer 320 hd600's -- so, what's happening with yours? are they falling apart?
I might be mistaken, but I think that the 800's silver paint is prone to chipping. I remember that Jude recommended using a silver Sharpie to fix the issue at the LA Headfi meet.
As much as I'd like to say I was the clever one who came up with that, it wasn't me. The first mention I've found of the silver Sharpie for the HD 800 is here (by DucatiMatt):
http://www.head-fi.org/t/426508/sennheiser-hd800-appreciation-thread/3240#post_8271673
(By the way, dsound, thank you again for the glass at the meet! I'll PM you separately about that.)
using foobar2000 in the configuration for output there is a "wasapi: speakers: event: odac" and a "wasapi: speakers: push: odac"
is there any difference between them, i noticed a slight difference when i changed the output from default to the wasapidac but it's hard to tell between the event/push.
Found this on Jriver site
WASAPI output mode pushes data from Media Center to the sound device. It works with nearly all hardware.
WASAPI Event Style lets a sound device pull data from Media Center. This method is not supported by all hardware, but is recommended when supported.
This has several advantages:
- It lets the audio subsystem pull data (when events are set) instead of pushing data to the system. This allows lower latency buffer sizes, and removes an unreliable Microsoft layer documented below.
- It creates, uses, and destroys all WASAPI interfaces from a single thread.
- The hardware (or WASAPI interface) never sees 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.).
- It allows for a more direct data path to the driver / hardware.
- The main 'pull loop' uses a lock-free circle buffer (a system that J. River built for ASIO), so that fullfilling a pull request is as fast as possible.
...Then again, if you can't hear a difference, it doesn't matter.