|
Post by rogersch on May 20, 2015 7:22:53 GMT -5
I am stuck with an issue that appears to be a bug in how XMC-1 handles changes to USB Stream input: I have my HTPC connected to XMC-1 via HDMI1 and USB Stream. Only JRiver plays thru the USB in exclusive mode, all other applications via HDMI. I also have my Oppo connected via HDMI2. Input buttons: * Input1 => Audio=HDMI1 Video=HDMI1 * Input2 => Audio=USBStream Video=HDMI1 * Input3 => Audio=HDMI2 Video=HDMI2 What I noticed is that often (but not always), changing from Input1 to Input2 and playing a track in JRiver, no sound comes up, despite JRiver saying it's playing. However, by changing to input3 and then back to input2, I can finally hear what JRiver is playing. Basically, forcing a HDMI handshake forces XMC-1 to finally play what is being streamed. I'm curious to know why you would play audio of JRiver via USB as the HTPC is also connected via HMDI to the XMC-1. Why not play everything via HDMI?
|
|
|
Post by novisnick on May 20, 2015 9:24:12 GMT -5
I am stuck with an issue that appears to be a bug in how XMC-1 handles changes to USB Stream input: I have my HTPC connected to XMC-1 via HDMI1 and USB Stream. Only JRiver plays thru the USB in exclusive mode, all other applications via HDMI. I also have my Oppo connected via HDMI2. Input buttons: * Input1 => Audio=HDMI1 Video=HDMI1 * Input2 => Audio=USBStream Video=HDMI1 * Input3 => Audio=HDMI2 Video=HDMI2 What I noticed is that often (but not always), changing from Input1 to Input2 and playing a track in JRiver, no sound comes up, despite JRiver saying it's playing. However, by changing to input3 and then back to input2, I can finally hear what JRiver is playing. Basically, forcing a HDMI handshake forces XMC-1 to finally play what is being streamed. I'm curious to know why you would play audio of JRiver via USB as the HTPC is also connected via HMDI to the XMC-1. Why not play everything via HDMI? Please excuse my interruption but I've found that music through USB sounds better then that from HDMI, my room, gear and ears. Just two cents my friend.
|
|
|
Post by makutaku on May 20, 2015 11:48:55 GMT -5
I am stuck with an issue that appears to be a bug in how XMC-1 handles changes to USB Stream input: I have my HTPC connected to XMC-1 via HDMI1 and USB Stream. Only JRiver plays thru the USB in exclusive mode, all other applications via HDMI. I also have my Oppo connected via HDMI2. Input buttons: * Input1 => Audio=HDMI1 Video=HDMI1 * Input2 => Audio=USBStream Video=HDMI1 * Input3 => Audio=HDMI2 Video=HDMI2 What I noticed is that often (but not always), changing from Input1 to Input2 and playing a track in JRiver, no sound comes up, despite JRiver saying it's playing. However, by changing to input3 and then back to input2, I can finally hear what JRiver is playing. Basically, forcing a HDMI handshake forces XMC-1 to finally play what is being streamed. I'm curious to know why you would play audio of JRiver via USB as the HTPC is also connected via HMDI to the XMC-1. Why not play everything via HDMI? First benefit is that JRiver can get exclusive control of the USB without ever interfering with the other apps, including Windows. Second benefit is less jitter when using the USB.
|
|
|
Post by rogersch on May 20, 2015 14:23:04 GMT -5
I'm curious to know why you would play audio of JRiver via USB as the HTPC is also connected via HMDI to the XMC-1. Why not play everything via HDMI? Please excuse my interruption but I've found that music through USB sounds better then that from HDMI, my room, gear and ears. Just two cents my friend. Okay. In my case I couldn't hear any difference but then again I don't use windows for my HTPC. I use OpenElec as HTPC software.
|
|
|
Post by rogersch on May 20, 2015 14:27:37 GMT -5
I'm curious to know why you would play audio of JRiver via USB as the HTPC is also connected via HMDI to the XMC-1. Why not play everything via HDMI? First benefit is that JRiver can get exclusive control of the USB without ever interfering with the other apps, including Windows. Second benefit is less jitter when using the USB. Can somebody explain to me how jitter can be an issue if the signal is very heavy digitally processed (DIRAC) before it is sent to the DAC's? See also my previous post about using other HTPC software (like OpenElec) to get rid of unwanted interference / manipulation of the audio signal by windows. (Maybe a WASAPI audio driver in the mediaplayer software might also solve the problem).
|
|
|
Post by novisnick on May 20, 2015 14:28:42 GMT -5
rogersch, I've compared using Mac Mini and a PC, still prefer Mac Mini USB for two channel digital, unless you want to talk ERC-2. 8)
|
|
|
Post by makutaku on May 20, 2015 16:52:57 GMT -5
To be honest I didnt have a chance to setup Dirac and compare.
Jitter aside, another real benefit is that powering off the TV wont interfer with the music that is being played, making it immune to the HDMI handshaking crap.
|
|
|
Post by rogersch on May 21, 2015 1:03:27 GMT -5
another real benefit is that powering off the TV wont interfer with the music that is being played, making it immune to the HDMI handshaking crap. That is a very valid point!
|
|
|
Post by badwolf on Jun 26, 2015 13:41:39 GMT -5
Question... Just ordered a qnap 251 for music streaming and have a rasaberry pi.... best way to get music to xmc? direct connect or though roku p3 or pi? tips and working ideas appreciated Thanks
|
|
|
Post by qdtjni on Jul 2, 2015 8:11:14 GMT -5
Yesterday, I had a breakthrough with USB streaming to the XMC-1. As I continued to test, it became evident that I could only USB Stream from my Picoreplayer Raspberry Pi in 16 bit mode. I had to use -o HW:0,0 -a 80:4:16:0 which are the Alsa settings. Any other settings resulted in noise and distortion on the output. I thought I was at a dead end but due to the tireless efforts of Steen (author of the Picoreplayer distro) he uncovered a possible solution that has brought to light an OS bug related to CMedia USB chips that now is being worked on. Here is the fix that has worked for me: If you are willing to edit the cmdline.txt file you could try this:
1. Delete your string looking something like this: dwc_otg.fiq_fsm_mask=0x7 (the 0x7 can be a different value - doesn't matter simply delete it all). 2. Then add this: dwc_otg.fiq_fsm_enable=0 to your cmdline.txt file.
Note: If you insert the SD-card in a windows computer you can easily see and edit the cmdline.txt file. Then save the changes and reboot your raspberry.
Regards Steen USB Audio bug discussionI can now use alsa settings of -o HW:0,0 -a 80:4:: which means I am now running in 24bit mode. The discovery of this bug and this workaround until a real fix is available will probably help a number of DACs that use the the Cmedia chipset including Emotiva and some of the Schitt DACs. -CB I tried the above fix and it worked well for me as well. Very good find, Chris!
|
|
|
Post by meridion on Jul 18, 2015 4:28:21 GMT -5
Yesterday, I had a breakthrough with USB streaming to the XMC-1. Here is the fix that has worked for me: If you are willing to edit the cmdline.txt file you could try this:
1. Delete your string looking something like this: dwc_otg.fiq_fsm_mask=0x7 (the 0x7 can be a different value - doesn't matter simply delete it all). 2. Then add this: dwc_otg.fiq_fsm_enable=0 to your cmdline.txt file.
Note: If you insert the SD-card in a windows computer you can easily see and edit the cmdline.txt file. Then save the changes and reboot your raspberry.
Regards Steen I can now use alsa settings of -o HW:0,0 -a 80:4:: which means I am now running in 24bit mode. The discovery of this bug and this workaround until a real fix is available will probably help a number of DACs that use the the Cmedia chipset including Emotiva and some of the Schitt DACs. Until today my PiCorePlayer setup worked perfectly in hires mode, although this seemed to be a miracle somehow. Today I updated to 1.19l and it stopped working. Back to the experience everybode else had... With Steens fix, it seems to be perfectly working (in hires mode) again. Thanks for your effort.
|
|
|
Post by Thunderduck on Aug 13, 2015 16:34:28 GMT -5
When installing the Emotiva C-Media USB Drivers for Windows 10, do I make the connection to the back of the XMC using the USB Stream Input connector?
Thanks for the help.
Steve
Edit: Never mind. Short answer is yes. I also did get an error message after the installation, however, everything was found and worked fine. So appears that can be ignored.
|
|
|
Post by pjmbarlick on Aug 14, 2015 20:20:00 GMT -5
I have just installed my new XMC1 I have a Mac mini connecting to the XMC via Usb and hdmi
I also own the full retail suite of dirac live which I run on my Mac mini
The funny thing is when i run Dirac live, it sees the hdmi connection and says it supports 192khz, but the when it use the USB correction it reports a maximum of 96 kHz
Given that the dac is the same for both connections Should I assume that the lower sample rate reported via USB is an issue with emotiva implementing the dac differently via USB?
Also I notice that when using usb the info display everything as 24 but even when the software players are correctly reporting 16 but playback.
Any ideas anyone for a newbie???
|
|
|
Post by goodfellas27 on Aug 19, 2015 10:17:01 GMT -5
I have just installed my new XMC1 I have a Mac mini connecting to the XMC via Usb and hdmi I also own the full retail suite of dirac live which I run on my Mac mini The funny thing is when i run Dirac live, it sees the hdmi connection and says it supports 192khz, but the when it use the USB correction it reports a maximum of 96 kHz Given that the dac is the same for both connections Should I assume that the lower sample rate reported via USB is an issue with emotiva implementing the dac differently via USB? Also I notice that when using usb the info display everything as 24 but even when the software players are correctly reporting 16 but playback. Any ideas anyone for a newbie??? Playing music in Windows via HDMI is doing its own processing before sending the file via HDMI in PCM format to the XMC-1 for reprocessing . The default sampling rate it scales is 192K. The USB play sound in async mode. Using WASAPI, your music file is transported to XMC-1 untouched. This would give you better sound quality and you would see the native 96K of your file, 44K for CDs, etc. If you're playing a native 192K file via USB using WASAPI and still see 96K, then you may need to update your XMC-1 USB firmware. Check the bottom of the resource page for the drivers: emotiva.com/products/pres-and-pros/xmc-1 WASAPI: emotiva.com/resources/updates/Configuring_WASAPI_Mode_in_Audio_Players.pdf
|
|
|
Post by millst on Aug 19, 2015 11:18:02 GMT -5
WASAPI only applies to Windows computer. That's what the W in WASAPI stands for. Using HDMI in Windows does not necessarily mean there is additional processing, e.g. WASAPI can be used for outputting to an HDMI audio device. The default sample rate is not necessarily 192k. It is either controlled by the audio device properties panel or, in the case of WASAPI exclusive, the audio application's settings.
I'm not very familiar with Apple computers, which is what the poster has. It's possible the XMC-1 has the old firmware, but it could also be an issue with the audio drivers or player.
-tm
|
|
|
Post by doc1963 on Aug 19, 2015 13:02:06 GMT -5
The USB digital audio output settings on a Macintosh computer are governed by the "Audio MIDI Setup" utility found in the Utilities folder. Using that utility, make sure the Mac "sees" the XMC-1 and that you have it set as the default audio output device. Also make sure that the bit depth shown is correct and the output sampling frequency is set to the highest option available. For the XMC-1, that will be 24bit/192kHz. There is some odd behavior between the Mac and the XMC-1. If your Mac doesn't see the XMC-1's full assortment of "capable" sampling frequencies (and you're sure your XMC-1 has the latest USB firmware), then unplug the USB cable from the back of the Mac, shut down the Mac and restart. Reboot the XMC-1 and wait a few minutes for both to stabilize. Plug the USB cable back into the Mac, wait a minute, then go to the MIDI utility and see what it now says. If the Mac now sees the XMC-1 as a 24 bit/192kHz capable device, then you're good to go. If you aren't successful, leave the Mac running, but reboot the XMC-1 until the Mac's MIDI utility sees the correct settings. It is important, however, to give the XMC-1 a minute to stabilize and report itself to the Mac. Both are computers and may take a minute or two to communicate. Once you are successful, it is "my" advice to never shut down or restart the Mac again unless you absolutely must (OS software update for example). FWIW, my XDA-1, XDA-2 and (now) my XMC-1 behave exactly the same way with my Mac Mini. The only Emotiva branded DAC that connected every single time, without a hitch, was my DC-1. Maybe the DC-1 used a different USB board. As for the XMC-1 reporting "24 bit", that is correct. The XMC-1's DAC operates in a 24 bit "native" mode. Most " intelligent" source devices will "pad" 16 bit data up to 24 bit to avoid the delay involved in rebooting the DAC. The original 16 bit data is unharmed (by padding) and you would never know the difference if the XMC-1's display didn't (accurately) tell you so... Hope this helps...
|
|
|
Post by namikis on May 23, 2016 22:21:54 GMT -5
First benefit is that JRiver can get exclusive control of the USB without ever interfering with the other apps, including Windows. Second benefit is less jitter when using the USB. Can somebody explain to me how jitter can be an issue if the signal is very heavy digitally processed (DIRAC) before it is sent to the DAC's? See also my previous post about using other HTPC software (like OpenElec) to get rid of unwanted interference / manipulation of the audio signal by windows. (Maybe a WASAPI audio driver in the mediaplayer software might also solve the problem). In my case it became very obvious quickly (to me) that flacs/mp3s/dsf files in Jriver sounded noticeable better through USB. I have an Audioquest jitterbug and a separate powered hub feeding the Audioquest on the signal's way to the processor. The difference vs. HDMI was not trivial!
|
|
edrummereasye
Sensei
"This aggression will not stand, man!"
Posts: 438
|
Post by edrummereasye on Jul 18, 2016 9:18:42 GMT -5
Can somebody explain to me how jitter can be an issue if the signal is very heavy digitally processed (DIRAC) before it is sent to the DAC's? See also my previous post about using other HTPC software (like OpenElec) to get rid of unwanted interference / manipulation of the audio signal by windows. (Maybe a WASAPI audio driver in the mediaplayer software might also solve the problem). In my case it became very obvious quickly (to me) that flacs/mp3s/dsf files in Jriver sounded noticeable better through USB. I have an Audioquest jitterbug and a separate powered hub feeding the Audioquest on the signal's way to the processor. The difference vs. HDMI was not trivial! The USB DAC in the XMC-1 is asynchronous, meaning it re-clocks the incoming data stream. Jitter is not a concern. And yes, Emotiva themselves recommend using WASAPI / WASAPI Push drivers with Windows to ensure bit-perfect output.
|
|
abd1
Minor Hero
Posts: 29
|
Post by abd1 on Mar 10, 2017 15:02:25 GMT -5
Trying to do the firmware update and when I put my USB stick in the menu just says no USB Stick. I've tried powering on/off, both f/b usb ports, and made sure the only file I have on my stick is the update. Thoughts? The menu says this all the time btw.
|
|
|
Post by doc1963 on Mar 10, 2017 15:13:13 GMT -5
Trying to do the firmware update and when I put my USB stick in the menu just says no USB Stick. I've tried powering on/off, both f/b usb ports, and made sure the only file I have on my stick is the update. Thoughts? The menu says this all the time btw. The "USB Stream" driver update cannot be performed from a USB thumbdrive (like the regular "firmware" update). The XMC-1 must be connected to your computer to update the USB firmware. A full set of instructions can be found on the XMC-1 product page under the "Resources" tab. Hope this helps...
|
|