Hi Lucas,
Nope, not as far as I know. As I have an opened up AE 802.11b/g but no USB DAC to connect, I can't verify this myself, but I don't see any reason why it wouldn't be worth the try. Class compliance dictates that the behaviour should be the same – although Apple is infamous for intentionally circumventing standards.
But as it isn't difficult to try, why not give it a shot and report back...
I think I wrote it previously: once you're hooked, you can't have enough of them. So a spare (the old one) for another room wouldn't hurt anyway.
I don't see how signal processing would be simplified. It would be USB communication and a serial data stream in both cases. You'd just be ending up using the other DAC.
Cheers,
Sebastian.
Nope, not as far as I know. As I have an opened up AE 802.11b/g but no USB DAC to connect, I can't verify this myself, but I don't see any reason why it wouldn't be worth the try. Class compliance dictates that the behaviour should be the same – although Apple is infamous for intentionally circumventing standards.
But as it isn't difficult to try, why not give it a shot and report back...
I think I wrote it previously: once you're hooked, you can't have enough of them. So a spare (the old one) for another room wouldn't hurt anyway.
I don't see how signal processing would be simplified. It would be USB communication and a serial data stream in both cases. You'd just be ending up using the other DAC.
Cheers,
Sebastian.
Hi Lucas,
Nope, not as far as I know. As I have an opened up AE 802.11b/g but no USB DAC to connect, I can't verify this myself, but I don't see any reason why it wouldn't be worth the try. Class compliance dictates that the behaviour should be the same – although Apple is infamous for intentionally circumventing standards.
But as it isn't difficult to try, why not give it a shot and report back...
I think I wrote it previously: once you're hooked, you can't have enough of them. So a spare (the old one) for another room wouldn't hurt anyway.
I don't see how signal processing would be simplified. It would be USB communication and a serial data stream in both cases. You'd just be ending up using the other DAC.
Cheers,
Sebastian.
Ah, OK. The fact that I can't find a single reference on the internet to a USB output being achieved on an Airport Express, new or old, suggests to me that it can't be done. I have seen no reference to success, and been told by a man who sold an extensively modded the old Airport Express that USB is not possible and that achieving I2S output was a matter of making a new board to accommodate a new chip. I think that's reason enough to quit this experiment. If Airport Express could be USB out as simply as you say, somebody would have done it in the last 7 years, of that I am 100% sure.
What I now intend to do is buy a newer "n" version and tap i2s from it.
Many thanks
Lucas
Hi Sebastian.
Thanks for that link. I'm a little confused, as my Airport Express, which dates back to the same period (2004) doesn't have the PCM2707 at all, but the PCM2705. I had read that all AE's of the "g" era, were 2704 and 2705, and that later "n" AEs were 2706 and 2707.
I'm not sure whether to press on with this or not now or get the new one...
Thanks again,
Lucas
Thanks for that link. I'm a little confused, as my Airport Express, which dates back to the same period (2004) doesn't have the PCM2707 at all, but the PCM2705. I had read that all AE's of the "g" era, were 2704 and 2705, and that later "n" AEs were 2706 and 2707.
I'm not sure whether to press on with this or not now or get the new one...
Thanks again,
Lucas
You're welcome.
His new DAC has got the PCM2707 in it, not his AE. Which proves that he was able to simply connect a different USB device to the AE's PCM2705's USB solder pads (after disconnecting pins 8 and 9 of the IC, of course).
That was my point, the original AE's internal USB port can be used with other (class compliant) USB DACs. Limited to 16bit/48kHz, though.
Cheers,
Sebastian.
Thanks once again Sebastian.
Well, on Sunday when I was all excited about this, I disconnected my AE's internal USB port from the circuit board, so that I could use it to wire the port directly to the chip pads and have a useable USB port too. I cut, with sharp nail scissors, the pins 8 and 9, at the top where they meet the chip, so that I could hopefully use them to link to the pads, which are tiny.
This is micro-soldering, for robots!
There's no going back now, so I will press on then, and soon I will report back in the next few days with my results.
Many thanks
Lucas
Well, on Sunday when I was all excited about this, I disconnected my AE's internal USB port from the circuit board, so that I could use it to wire the port directly to the chip pads and have a useable USB port too. I cut, with sharp nail scissors, the pins 8 and 9, at the top where they meet the chip, so that I could hopefully use them to link to the pads, which are tiny.
This is micro-soldering, for robots!
There's no going back now, so I will press on then, and soon I will report back in the next few days with my results.
Many thanks
Lucas
Well, I just did the same thing yesterday, as I wanted to prove (wrong) wether it really works.
I borrowed an M-Audio Fasttrack Pro, a device which is an example of a class compliant audio codec that also has extended capabilities once a driver is used (but will still work in 16bit/48kHz without dedicated driver).
I then cut pins 8 and 9 off the PCM2705 in my 2004' AE and prepared two USB cables by stripping and tinning: one type B (which goes to the PCB) to connect the AE to said M-Audio device and one type A (which goes to the IC pins) in order to connect the AE's unplugged audio daughter board to a regular computer.
We'll see how it goes.
Oh, and there's always a way back. Those cut solder pins can be bridged with i.e. thin wire (like a litz strand) using large amounts of solder flux and desoldering tools as an aid. The whole IC isn't expensive anyway.
I borrowed an M-Audio Fasttrack Pro, a device which is an example of a class compliant audio codec that also has extended capabilities once a driver is used (but will still work in 16bit/48kHz without dedicated driver).
I then cut pins 8 and 9 off the PCM2705 in my 2004' AE and prepared two USB cables by stripping and tinning: one type B (which goes to the PCB) to connect the AE to said M-Audio device and one type A (which goes to the IC pins) in order to connect the AE's unplugged audio daughter board to a regular computer.
We'll see how it goes.
Oh, and there's always a way back. Those cut solder pins can be bridged with i.e. thin wire (like a litz strand) using large amounts of solder flux and desoldering tools as an aid. The whole IC isn't expensive anyway.
Can you link me to the relevant section, with some advice on implementing this please. I am about to attempt it and the photo alone is a bit risky.
many thanks
Lucas
Question on I2s connection: what wires should be used? I've read that ethernet UTP 5 or 6 twisted pair is OK, but I don't understand how to connect it correctly. Which signals should be in pair? We've got 3 wires + ground, so what's the order? UPT has 4 pairs, and each pair has unique step length...
Last edited:
Hi Vitalbesson and CDFR
I have an AD1865 based DAC with only coax input - I have allready modified my DAC and currently route spdif signal from my CD-player directly to Digital-in on the DAC's CS8414 chip.
I plan to do the same as you have tried - routing the D-out from AE direct to DAC's digital in and keeping the distance short (5-10cm).
Is it not clear for me if I can just take the spdif signal directly from label 7# (see attached picture from CDFR french thread) and wire it directly to Digital-in on my DAC's CS8414 chip? Do I need any coupling cap/transformer/resistor in between the connections?
Sorry for asking newbie question but hope you can help me out on this - thanks
Søren
Attachments
Hi Lucas.
Sorry for the delay but I am too busy these days.
I have not tried the I2S connection myself so I can't guide you.
However in my research I identified that the DAC on the AE-N was a CS4344 (see the picture on my french post: Modification Airport Express (Zardoz, Rosita, Airstream...) - Page 17 - Sources).
Using the datasheet of the DAC should provide you the info you need.
The other alternative is to copy is to use the same connections as the ones used by Clemaster, but it' true that all the details are not there. He picks 1 signal on the DAC, and for the MCLK he elected to pick it on the R718 PAD instead of the DAC. For the LRCK he does not say, may be R717?
Modification Airport Express (Zardoz, Rosita, Airstream...) - Page 22 - Sources
Sorry for the delay but I am too busy these days.
I have not tried the I2S connection myself so I can't guide you.
However in my research I identified that the DAC on the AE-N was a CS4344 (see the picture on my french post: Modification Airport Express (Zardoz, Rosita, Airstream...) - Page 17 - Sources).
Using the datasheet of the DAC should provide you the info you need.
The other alternative is to copy is to use the same connections as the ones used by Clemaster, but it' true that all the details are not there. He picks 1 signal on the DAC, and for the MCLK he elected to pick it on the R718 PAD instead of the DAC. For the LRCK he does not say, may be R717?
Modification Airport Express (Zardoz, Rosita, Airstream...) - Page 22 - Sources
Hi Rolle,
I tried using the transformer, it worked fine. However when I saw the shape of the signal at the receiving end in my DAC, I decided to bypass all this and connect it directly to the input of the CS8411 that my DAC uses. You might want to check what the CS8414 accepts in the datasheet.
Cheers.
I tried using the transformer, it worked fine. However when I saw the shape of the signal at the receiving end in my DAC, I decided to bypass all this and connect it directly to the input of the CS8411 that my DAC uses. You might want to check what the CS8414 accepts in the datasheet.
Cheers.
Hi Guys. Fascinating thread, and very helpful. I am not as technical so please forgive what may be a trivial question.
I am trying to determine what is the highest fidelity way to reproduce uncompressed music stored on an Ipod and sent via Airplay to an Airplay receiver. I want the convenience of being able to control volume via the Ipod whilst minimising the 'lost bits' problem. I'd like to pass the digital output of an Airport Express (802.11n version) to an external DAC, and on to powered speakers. What I don't understand is how the AX deals with volume control initiated on the Ipod. My understanding is that Airplay uses RAOP, and that in theory the control channel of RAOP could allow the Airplay receiver to attenuate any way it saw fit. In practice, how does the AX do this? I presume the AX receives a 16 bit input, and applies an 8 bit multiplier to gain/attenuate it, creating 24 bit words. Is that right? If so, it seems to me that one of the following (or something else!) then happens :
i) Does the AX then output these 24 bit words to SPDIF? If so presumably a decent external 24 bit DAC would be able to create good quality analogue sound output.
ii) Does the AX dither the 24 bit words and then convert them back to 16 bit before outputting them to SPDIF? If so is the dithering done well? This would presumably enable an external DAC to create reasonably decent analogue.
iii) Does the AX do neither of the above but simply truncate the 24 bit words back to 16 bit words and then send them to SPDIF? If so this would result in serious loss of audio data.
Do any of the 3rd party mods mentioned above deal with this issue? e.g. Micromega, Zardoz? Or is the AX on its own adequate (at least in this respect)?
Any guidance gratefully received!
[PS my assumption is that if you send uncompressed music from an Ipod via Airplay it is sent uncompressed. Is that right?]
Cheers,
Mike
I am trying to determine what is the highest fidelity way to reproduce uncompressed music stored on an Ipod and sent via Airplay to an Airplay receiver. I want the convenience of being able to control volume via the Ipod whilst minimising the 'lost bits' problem. I'd like to pass the digital output of an Airport Express (802.11n version) to an external DAC, and on to powered speakers. What I don't understand is how the AX deals with volume control initiated on the Ipod. My understanding is that Airplay uses RAOP, and that in theory the control channel of RAOP could allow the Airplay receiver to attenuate any way it saw fit. In practice, how does the AX do this? I presume the AX receives a 16 bit input, and applies an 8 bit multiplier to gain/attenuate it, creating 24 bit words. Is that right? If so, it seems to me that one of the following (or something else!) then happens :
i) Does the AX then output these 24 bit words to SPDIF? If so presumably a decent external 24 bit DAC would be able to create good quality analogue sound output.
ii) Does the AX dither the 24 bit words and then convert them back to 16 bit before outputting them to SPDIF? If so is the dithering done well? This would presumably enable an external DAC to create reasonably decent analogue.
iii) Does the AX do neither of the above but simply truncate the 24 bit words back to 16 bit words and then send them to SPDIF? If so this would result in serious loss of audio data.
Do any of the 3rd party mods mentioned above deal with this issue? e.g. Micromega, Zardoz? Or is the AX on its own adequate (at least in this respect)?
Any guidance gratefully received!
[PS my assumption is that if you send uncompressed music from an Ipod via Airplay it is sent uncompressed. Is that right?]
Cheers,
Mike
Mike,
The AE-N is fully capable of handling 24/96 however at this time there is no proof that anything else than 16bit is used.
People who have looked at the protocol (wikipedia) found 16 bit I think.
The spdif output of the AE-N is so far only 16 bit as well.
How the volume control is handled is TBD. Is it from the source itunes or the iThing? (in that case it seems probable that you are loosing bits) or is it the AE-N who upsamples and dithers...
I don' know. I suspect that it is the source that does the volume control and that dithering or not bits are lost.
It sounds still ok though.
The AE-N is fully capable of handling 24/96 however at this time there is no proof that anything else than 16bit is used.
People who have looked at the protocol (wikipedia) found 16 bit I think.
The spdif output of the AE-N is so far only 16 bit as well.
How the volume control is handled is TBD. Is it from the source itunes or the iThing? (in that case it seems probable that you are loosing bits) or is it the AE-N who upsamples and dithers...
I don' know. I suspect that it is the source that does the volume control and that dithering or not bits are lost.
It sounds still ok though.
Hi,
The CODEC in the AE-N is confirmed to be capable of 24/96. The audio encoding Apple Lossless (Wikipedia) is known to be capable of 24/96 as well, although iTunes has it's problems with preserving bitrate and sampling frequency during different conversion steps...
But the Remote Audio Output Protocol (Wikipedia) which is Apple's implementation (known as AirTunes/AirPlay) of the more general Real Time Streaming Protocol (Wikipedia) is not, it is limited to 16/44.1.
This has been confirmed in the unofficial Airtunes 2 Specification, although it's not an inevitable limitation. Apple just never extended this property of their protocol specification towards 24/96, presumably because they never felt the need.
Airport Express implements a Human Interface Device (HID). The original goal was to have a remote control connected to the AE. This worked right from the beginning via the AE's USB port.
An example of an actual remote control device used to be Griffin's AirClick, another one was Keyspan's Express Remote (Amazon).
You could actually control play, pause, etc.
Beware, I didn't check compatibility to Windows 7, Snow Leopard, Lion and AE-N!
That depends on the AirPlay device in use, and it changed with the different AE and AirTunes/AirPlay generations.
In general, iTunes (or the AirPlay server) does an ASRC (if neccessary) and sets the output volume for Airport Express. With some other devices audio data is transferred at full volume. This is different from just truncating some bits. Technically, volume reduction can never be had without losing some resolution, though.
AE (or an AirPlay client) simply receives and decodes the stream, usually no further downsampling is neccessary. Clients such as AppleTV, iOS devices or Zeppelin Air implement their own volume control, usually in the digital domain. Such devices can be recognized by making the volume control in iTunes or iOS unavailable.
iTunes has a switch that disables the local AirPlay volume control and enforces volume control on the receiving end even for Airport Express. This enables you to ensure full resolution (16/44.1) and lossless transfer (via ALAC, via RAOP). Just not up to 24/96.
iTunes is pretty good at doing it's ASRC. After all, it's QuickTime at work!
Cheers,
Sebastian.
The CODEC in the AE-N is confirmed to be capable of 24/96. The audio encoding Apple Lossless (Wikipedia) is known to be capable of 24/96 as well, although iTunes has it's problems with preserving bitrate and sampling frequency during different conversion steps...
But the Remote Audio Output Protocol (Wikipedia) which is Apple's implementation (known as AirTunes/AirPlay) of the more general Real Time Streaming Protocol (Wikipedia) is not, it is limited to 16/44.1.
This has been confirmed in the unofficial Airtunes 2 Specification, although it's not an inevitable limitation. Apple just never extended this property of their protocol specification towards 24/96, presumably because they never felt the need.
Airport Express implements a Human Interface Device (HID). The original goal was to have a remote control connected to the AE. This worked right from the beginning via the AE's USB port.
An example of an actual remote control device used to be Griffin's AirClick, another one was Keyspan's Express Remote (Amazon).
You could actually control play, pause, etc.
Beware, I didn't check compatibility to Windows 7, Snow Leopard, Lion and AE-N!
That depends on the AirPlay device in use, and it changed with the different AE and AirTunes/AirPlay generations.
In general, iTunes (or the AirPlay server) does an ASRC (if neccessary) and sets the output volume for Airport Express. With some other devices audio data is transferred at full volume. This is different from just truncating some bits. Technically, volume reduction can never be had without losing some resolution, though.
AE (or an AirPlay client) simply receives and decodes the stream, usually no further downsampling is neccessary. Clients such as AppleTV, iOS devices or Zeppelin Air implement their own volume control, usually in the digital domain. Such devices can be recognized by making the volume control in iTunes or iOS unavailable.
iTunes has a switch that disables the local AirPlay volume control and enforces volume control on the receiving end even for Airport Express. This enables you to ensure full resolution (16/44.1) and lossless transfer (via ALAC, via RAOP). Just not up to 24/96.
iTunes is pretty good at doing it's ASRC. After all, it's QuickTime at work!
Cheers,
Sebastian.
Last edited:
Thanks Chaps.
Sebastian, the article about ASRC is beyond my skills, I'm afraid!
My desire is to get uncompressed 16/44.1 music files streamed uncompressed from an Ipod to an AirPlay enabled device (AE, ATV or other) with as little corruption caused by volume control as possible, but still retaining the convenience of controlling volume from the Ipod.
You mention that AE implements HID, e.g. the AirClick device. This suggests that the AE has a local (client side) digital or analogue method of attenuating volume. Later you suggest that Itunes or an AirPlay server attenuates volume at source using ASRC and sends the modified bitstream to the AE which simply DACs it with no local volume control. This sounds like server-side digital attenuation. So do you mean that AE is capable of both? If an Ipod is streaming via Airplay to AE how is volume controlled?
It seems to me that you suggest that when an Ipod streams to other AirPlay devices such as Zeppelin Air the volume control is not usable on the Ipod. Have I got that right? I would have thought it would be better for AirPlay devices to have a post-DAC analogue volume control controlled by the control channel of RAOP so that vol could be set on the Ipod GUI....
Cheers,
Mike
Sebastian, the article about ASRC is beyond my skills, I'm afraid!
My desire is to get uncompressed 16/44.1 music files streamed uncompressed from an Ipod to an AirPlay enabled device (AE, ATV or other) with as little corruption caused by volume control as possible, but still retaining the convenience of controlling volume from the Ipod.
You mention that AE implements HID, e.g. the AirClick device. This suggests that the AE has a local (client side) digital or analogue method of attenuating volume. Later you suggest that Itunes or an AirPlay server attenuates volume at source using ASRC and sends the modified bitstream to the AE which simply DACs it with no local volume control. This sounds like server-side digital attenuation. So do you mean that AE is capable of both? If an Ipod is streaming via Airplay to AE how is volume controlled?
It seems to me that you suggest that when an Ipod streams to other AirPlay devices such as Zeppelin Air the volume control is not usable on the Ipod. Have I got that right? I would have thought it would be better for AirPlay devices to have a post-DAC analogue volume control controlled by the control channel of RAOP so that vol could be set on the Ipod GUI....
Cheers,
Mike
New Clock for the Apple AirPort Express
I would like to share my experience on upgrading the clock for AAE.
There are two SMT 25Mhz crystals under the AAE PCB. The one closer to the IC 88F6183 is about audio.
I removed this crystal (marked as Y700 on the PCB) and its load capacitors (C700 & C701) from the PCB.
And then, I soldered a blue wire to the clock input pad on the PCB and the white wire to the GND on the board.
Finally, the blue wire was connected to the clock output, and the white wire was connected to the clock ground. As a starting point, the clock currently used is a common 25MHz XO supplied by a regulator based on The Flea.
After this modification, the resulting sound is more smooth, more fluidly, and more liveness.
I am planning to try more clocks for the AAE.
TCXO with The Flea and Kwak Clock 7 will be tested in the future.
Simple and effective. Highly recommended.
I would like to share my experience on upgrading the clock for AAE.
There are two SMT 25Mhz crystals under the AAE PCB. The one closer to the IC 88F6183 is about audio.
I removed this crystal (marked as Y700 on the PCB) and its load capacitors (C700 & C701) from the PCB.
And then, I soldered a blue wire to the clock input pad on the PCB and the white wire to the GND on the board.
Finally, the blue wire was connected to the clock output, and the white wire was connected to the clock ground. As a starting point, the clock currently used is a common 25MHz XO supplied by a regulator based on The Flea.
After this modification, the resulting sound is more smooth, more fluidly, and more liveness.
I am planning to try more clocks for the AAE.
TCXO with The Flea and Kwak Clock 7 will be tested in the future.
Simple and effective. Highly recommended.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.