1audio

The static IP won't help. the problem comes from the startup sequence not getting a response from the NAS fast enough. We are working on the issue but its a bit of a tough nut to crack. for now just leave it on if you can. I never shut them off myself. Its a bit warm because its fanless and the heat differential is necessary to get rid of the heat. It actually creates a bit of an air current from the heat. Check with Ray in around a month and we should have progress on the startup issue you ran into.

There are some circumstances that make auto reconnect not work. Which version firmware do you have? Some earlier versions could have problems with this. Also some routers will change the IP address or delay the startup in ways that make it impossible to find the attached devices. More interesting is why you shut it down at night? Its like a router or a NAS or DVR and it draws not much power when its idle (less that 10W). On the PK100 the oscillators for the master clocks for the SPDIF will be more stable if its left on. Same for a DAC that is running in USB async mode.

You need to specify the mixer in two places in the config file. One is the section about output e.g. #mixer_control "PCM" # optional One for the mixer itself which you found: # Volume control mixer ######################################################## # # These are the global volume control settings. By default, this setting will # be detected to the available audio output device, with preference going to # hardware mixing. Hardware and software mixers for individual audio_output # sections cannot yet be mixed. # # An example for controlling an ALSA, OSS or Pulseaudio mixer; If this # setting is used other sound applications will be affected by the volume # being controlled by MPD. # #mixer_type "hardware" # # An example for controlling all mixers through software. This will control # all controls, even if the mixer is not supported by the device and will not # affect any other sound producing applications. # #mixer_type "software" # # This example will not allow MPD to touch the mixer at all and will disable # all volume controls. # mixer_type "disabled" # ############################################################################### I do not know the settings for your device (or any others from memory) Some implementations can take the volume control info from MPD and pass it to the DAC so the DAC's volume control is active. It works on some USB UAC1 devices I know from experience. USB UAC2 seems less settled in this area. There are some examples of code to implement this feature for specific devices, possibly part in ALSA and part in MPD.

Check the details on the Alix you have at the PCEngines site. It may not support suspend or hibernate (they have specific technical names, S1 and S3 I think). The USB power may still be on in hibernate to enable a keyboard to wake the system up. That would all be in the BIOS. Some aspects won't be changeable.

I got it to work. It needed some special tweaking that I no longer remember. It will be part of Alsa very soon. Its getting vetted now (lots of little things to make it fully compatible). I'm going to wait before investing more energy if the fully Alsa compliant version will be ready soon.

I tried to get the key guy behind Linux UAC2 to work on this. I even sent him an interface but it was not interesting enough to him at the time. I also pushed CMedia on this. They did have a fix but don't seem to understand open source. I think this fix is a good one and I'll try it on a brace of stuff around here. Linux changes sample rates way faster than OSX or Windows with the usual drivers (100 mS vs 1 mS for ALSA) and that is part of the problem. Its all standards compliant. . .

We have and do that in the Auraliti L1000. It is quite a major undertaking since separating the power from the PC interface was never intended by the designers of the interface. Given the failures and associated smoke I don't recommend it as a casual undertaking. It does help but its way down on the list if the host computer is not already quite special.

High Res and Bluetooth will be a problem since Bluetooth only runs at 44.1/16 and 48/16 (and 8K for voice). The device will need to sample rate convert which will stress the processor to its limits. Does it support AAC or APT-X over Bluetooth? SBC is pretty marginal for quality audio. Headphones always seem to sound better from a direct connection to the amp, however most headphone amps become unstable when directly connected to the load. You need to treat it like a power amp with an output matching network and possibly a Zobel to tame the load reactances.

Fantasy is nice but reality is less fun. 1) 20 GB/second isn't possible with anything a consumer can get. 2 GB/second maybe with UWB or 60 GHz but those guys have all gone out of business. 2) Wireless clocking is never good. Propagation irregularity is so great that you can only recover the core clock over time. GPS systems can take hours to get a good accurate clock fix, days to get decent timing accuracy. 3) 45M would probably be hazardous radiation levels. You can look at what the 60 GHz stuff does and the UWB stuff but the range is much less and power consumption way higher. I have tested pretty much every consumer wireless proposal and they all have significant limitations. Good news, no "i" names.

Good points and I think most of what I said earlier has been understood. First, current mid-fi gear is very good and in many cases will give a very good experience. Obsessive pursuit of better stuff is an aberration and probably not too healthy. That said, HDMI has three data cables and a clock cable in it. The audio is mixed on the data cables with the video, stuck in blank spaces that are defined by the video. The hardware grabs the audio from the stream and buffers it and then passes it out. And that is why the audio clocks and video clocks get mixed up which is not really a good thing. There are serious lip sync issues in HDMI and a number of efforts to deal with them. Usually the video is behind the audio and the audio is buffered to delay it so they are in sync. However the reveres is true when Bluetooth audio is used and the video may need delay. Some good sets have adjustments for lipsync. It can also be different between sources. There are some very good lightweight network players that have decent audio. I would look at what's possible with the Popcorn Hour Popcorn Hour - Networked Media Jukebox . There are a number of people hacking away at its firmware making many new things possible. I think it may support USB audio now as well as multichannel over HDMI.

Most any technical impediment can be an excuse if there is a way around it, but the price may be too high in one way or another. See "tractor beam" 'Star Trek' Prototype Tractor Beam Developed By Scientists . A lot to cover and some has already been. The easy ones- Oppo uses two HDMI ports because some HDMI receivers cannot pass 3D so one is for the receiver and the other is direct to the display. The audio connection to video clock tends to be tangential at best. The ratios are difficult to manage so it would not be a first choice if another alternative is available. USB for high resolution multichannel applications has been around for some time. However it was proprietary and it was not until the USB group got the players together to write a standard that the current async audio format took off. The current format is pretty similar to the the custom one that Creative hatched some time ago with products we have all forgotten. At higher sample rates jitter can be more significant since there is a wider band for jitter sensitivity to affect audio. But even jitter free audio doesn't help when a noisy computer power supply ground passes through your audio system. As I said earlier a new format is not a magic bullet. Its actually a trojan horse with many new pitfalls to discover. Most of those issues have been addressed and resolved in more mature formats. USB actually can handle more format options that AES, firewire or HDMI and do so for formats not even thought of yet. Isolation is hard for USB however.

The next smartphone interfaces are MHL (a variation on HDMI but uses none of the same physical layer) and USB. The Samsung Galaxy 3 supports UAC2 already. I would not say that USB is the default or go to interface for digital audio interfaces. Its one that works pretty well but firewire and AES/SPDIF also work well. A well executed I2S actually trumps all of the others by eliminating a lot of intervening stuff. There are something like 2 billion HDMI sockets in the world today so its a large opportunity but one not very interested in anything other than size. 3D was a flop. 4K (Ultra HD) may also be a flop. There are a handful of DAC's that will play DSD. None to my knowledge have an HDMI 1.2 or better input, necessary for SACD support. The HDMI standard only supports SACD (DSD 1X) and its not been a profit maker for anyone in the business so don't expect a lot. HDMI 2.0 is about to be released. It will push the goal posts for the technology but not do anything useful for audio as an independent format. Most HDMI sources need a TV on to control them. Fine for video but a distraction for audio. For what its worth I have been working with HDMI inc. since the format was announced and know the strengths and weaknesses well.

Actually most of the recommendations for USB are still true for a general purpose computer, even with USB3. Applications of large quantities of money and large customer bases can make even the worst sow's ear (DOS) into a silk purse (Windows 7 & 8). But you need to have a good reason to go there. HDMI was built for video out of a digital replacement for VGA (DVI). The audio was patched into DVI to make a consumer product. HDCP was added to get Hollywood on board. It worked and in a rather short period HDMI has replaced all other video connection schemes for consumers. Its also really technically demanding with 6+ Gbps per lane about to become reality. Yet audio is still a stepchild. The audio is buffered, packetized, inserted into horizontal refresh windows, sent across the wire, snaged, rebuffered and reclocked out using a regenerated clock (created using a complex phase locked loop). Its a lot of monkey motion to move audio. A PLL is used in every spdif receiver and can be much higher performance since its task is simpler. Toslink, AES and even SPDIF will have real isolation between source and destination (except for poor implementations of SPDIF) which is not possible for HDMI, unless you go to the fiberoptic solutions and most of those are not isolated. The current implementations are mostly based on the Silicon Image chips or pieces of them imbedded in other companies chips. They do what they need to for the application. A reclocker like the ones I mentioned will do wonders for the audio but destroy the lipsync. The HDCP rules are really restricting, not allowing any digital out higher than 48KHz regardless of the source content, so you need HDMI links all the way to the analog conversion. My experience has been that the BluRay players with analog outputs are a better starting point since the audio doesn't get mixed into the video in that scenario. Given the finite resources of the high end audio market there are better places to invest them.

Yes

I have a little experience with making HDMI products. The cost is much higher than it may appear. The licenses are part as are the test fees (approx $10K or more per device certified) and HDCP is a separate license and fee. The design is more difficult and the equipment to do it is way more expensive. To look at an HDMI data stream will set you back $100K or more. However its really a waste of time. HDMI is locked to video clocks generated at the host. The video clocks rarely have a relation to audio clocks. The PLL referenced in the paper is way poorer that most of the current generation SPDIF receivers. HDMI requires that the grounds be common on the source and the sink so you don't get benefits there. I think S/PDIF or AES-EBU are fundamentally better solutions, certainly than HDMI and when well implemented gives up little if anything to USB. Some of the new buffered reclocking schemes like the NuForce or this Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter - diyAudio are very effective at removing clock issues.