Wouldn't the G4 again double the amount of possible threads, and raise the amount of 1 bit ports? Of course it's a little bit more than the L2, both in pins and in price.
If it's possible to control the volume of the DAC using the Windows driver, I'd pay for that. It would make a very elegant solution, and much more versatile than what I had in mind to build initially.
Preferably this solution would need no customized driver at the OS side or the DAC side, so that it just works.
You could solve it by either doing multiple firmwares on the TPA, or you could have an extra controller which interprets the TPA volume commands and translates them so that the JT or DACs understand. Like the Volumite but instead of reading potentiometer position it reads what volume position the TPA reports.
This extra chip can then be swapped as easily as you can swap the firmware on the Volumite of course when firmware is needed to be changed =)
And since this is extra functionality you could set it as optional on the board to make a less bloated minimum kit, but I think many will want it
You could solve it by either doing multiple firmwares on the TPA, or you could have an extra controller which interprets the TPA volume commands and translates them so that the JT or DACs understand. Like the Volumite but instead of reading potentiometer position it reads what volume position the TPA reports.
This extra chip can then be swapped as easily as you can swap the firmware on the Volumite of course when firmware is needed to be changed =)
And since this is extra functionality you could set it as optional on the board to make a less bloated minimum kit, but I think many will want it
Last edited:
And to clarify another true and important beauty of OS controlled volume, I think you've understood but I'm saying again to be sure =)
One of my biggest wants for this is that there is no extra complexity to control volume from several volume controllers at the same time.
You could have for traditional wheel volume management, like "Griffin Powermate". Or why just one, maybe you sit in several areas so you want to have two? Just plug them both in the computer. Want a remote also? Just plug it in also.
To do this with the current Volumite isn't really possible, or would atleast require lots and lots of custom programming and building but if the OS-volume was interpreted it wouldn't be a problem, since OSes have already solved the multiple volume controllers issue.
// Olle
One of my biggest wants for this is that there is no extra complexity to control volume from several volume controllers at the same time.
You could have for traditional wheel volume management, like "Griffin Powermate". Or why just one, maybe you sit in several areas so you want to have two? Just plug them both in the computer. Want a remote also? Just plug it in also.
To do this with the current Volumite isn't really possible, or would atleast require lots and lots of custom programming and building but if the OS-volume was interpreted it wouldn't be a problem, since OSes have already solved the multiple volume controllers issue.
// Olle
And if one has more sources for the DAC than the USB module? Then one would need a computer connected to control the volume or also have a volumite/AC2 on the same I2C bus? And different driver for different OS's?
Sounds complex......
I would prefer AC2 with a nice iPhone/iPad remote control app.......
Sounds complex......
I would prefer AC2 with a nice iPhone/iPad remote control app.......
You could control the PC with an app like that, over the network. Controlling through both AC2 and PC would be difficult, as there's only one bus master allowed and both devices would try to take control.
I'm a bit sceptic about the AC2 making an appearance any time soon, I only vaguely remember my excitement about the AC1 more than 2 years ago... I'm likely going for a PC or Arduino instead as soon as this module appears.
So that would mean it would work out of the box on a MAC. Unfortunately there is no in-box driver for USB audio device class 2.0 compliant sound cards on Windows.
However, I guess your key point is that you would only need one driver per OS to get full integration with all appliactions and devices that work for controlling the volume on a PC or Mac.
That would also include remote control options since those are usually written to support the standard volume mixer on these OSes.
If the USB interface module would expose some interface to read or write the current volume setting that would allow us to integrate this with an Arduino or AC2. Ideally that volume setting would be made available via I2C so you could put it on the same bus as a Buffalo or Yoshua tree.
If there are simply not enough pins or CPU power on the current release then I take a stable hires USB sound interface rather sooner than later and wait for this feature in a future update.
Cheers
Thomas
Exactly, sure there isn't yet a standard USB Audio Class 2 Driver on Windows but the important with this solution to be really awesome would be that the only driver needed is a standard UAC2-driver, and not a customized TPA-driver.
// Olle
Which is exactly why that solution is bad
Right, the solution is a USB device model impemented in the TPA firmware that is compliant with the USB Audio device class 2.0 specifcation which is actually rather old. It was ratified in 2006 after many many years of deliberations.
So rather than invent something new the proposal is to follow the existing standard and complement the device model with a volume control in the audio controls attached to the audio endpoint.
I don't think there is really any discussion around that.
The question is how to expose this volume setting to the rest of the components in the DAC and make it adjustable by other means. One apparent solution would be to enable an client I2C port on the board and make the value available as a r/w register. That brings us back to the pins and CPU load
This could even be integrated into the Volumite firmware relatively simple. When the MCU on the Volumite initializes the I2C bus it could check for the existence of this device and if present regularly poll and execute volume updates from the computer as well as reflecting the current setting back so the mixer on a PC or Mac would track any changes performed on the Volumite. Probably easier though with a rotary encoder than a pot.
Cheers
Thomas
Last edited:
I don't have a dog in this race because my computer -> I2S solution goes up to 192/24 and should be good for a few years as the available music resolutions increase. But if I were waiting for a clean 192kHz USB interface from TPA, I certainly wouldn't embrace added delays for I2C volume control!
It would be an instant support headache. For example, the 'Remote' app that controls iTunes on a server via a WIFI iPod and iPad will spoil you fast and people will want to use whatever sophisticated remote control software they can get! I'm totally spoiled by 'Remote' and it is the reason I use iTunes for Win7 almost exclusively now. True, iTunes volume control is one of the 2 basic drawbacks but I accept it. I simply keep the system volume at ~66% and above and at 24 bits it is tolerable.
Obviously it would be sweet to have DAC volume control effectively built into programs like 'Remote', while overriding the server's system controls. However as a wish list item for the TPA prototype, I think it is unreasonable to thrust I2C control drivers upon Russ and Brian. Let's just see what the stereo prototype will do.
Frank
It would be an instant support headache. For example, the 'Remote' app that controls iTunes on a server via a WIFI iPod and iPad will spoil you fast and people will want to use whatever sophisticated remote control software they can get! I'm totally spoiled by 'Remote' and it is the reason I use iTunes for Win7 almost exclusively now. True, iTunes volume control is one of the 2 basic drawbacks but I accept it. I simply keep the system volume at ~66% and above and at 24 bits it is tolerable.
Obviously it would be sweet to have DAC volume control effectively built into programs like 'Remote', while overriding the server's system controls. However as a wish list item for the TPA prototype, I think it is unreasonable to thrust I2C control drivers upon Russ and Brian. Let's just see what the stereo prototype will do.
Frank
No need to override anything with this approach and no need to write an I2C control driver either. The only thing that needs to be written is to expose the volume control point the right way to the USB device so the standard OS volume control gets hooked up to this control point. That is a matter of advertizing the correct USB audio device topology to the OS via the standard USB configuration sequence.
From then on the OS will not use it's internal software volume control but send the corresponding control packets down to the USB device.
That works immediately with all players and all remore control software without any futher work on the PC or MAC side. If I am not completely mistaken then I believe then the XMOS sample driver already implements a volume control in the sample driver so you will not even have to figure out how to signal the correct topology.
Xmos USB Audio Software Design Guide said:
I guess the only work left to do is to expose this setting externally rather than perform the attenuation in software.
However, as I said. I would also like to see a stable bit transparent board rather sooner then later and will be patient to wait for this in a later revision. If there is any help needed on the driver I'd be happy to help.
Cheers
Thomas
Hi guys, please go easy this is my first post here. I'm reading as much as a can as fast as I can to try and get myself up to speed. I'm currently spec'ing up a dual mono Buffalo II DAC system and I suspect the forthcoming TP USB I2S will be the solution to my PC output needs.
I want to use the DAC both for listening pleasure and critical listening (mixing). So I'm wondering what the Windows drivers for the USB I2S will allow me to achieve.
I'm currently using Foobar with ASIO output through my EMU 1616M souncard. I also use DAW software capable of record and playback at 192KHz/24bit, also utilising the EMU's ASIO drivers. Ideally I want to ditch the EMU altogether but it all depends if the TP USB I2S will have an ASIO driver, or alternatively another very low latency solution that will accommodate Foobar (or alternative) and DAW requirements. I don't require anything more than 2 channels out of the PC and 2 channels in.
Thanks in advance for any help. All input greatly appreciated!
Cheers
I want to use the DAC both for listening pleasure and critical listening (mixing). So I'm wondering what the Windows drivers for the USB I2S will allow me to achieve.
I'm currently using Foobar with ASIO output through my EMU 1616M souncard. I also use DAW software capable of record and playback at 192KHz/24bit, also utilising the EMU's ASIO drivers. Ideally I want to ditch the EMU altogether but it all depends if the TP USB I2S will have an ASIO driver, or alternatively another very low latency solution that will accommodate Foobar (or alternative) and DAW requirements. I don't require anything more than 2 channels out of the PC and 2 channels in.
Thanks in advance for any help. All input greatly appreciated!
Cheers
Maybe it is possible to use ASIO4all with a Windows USB Audio class 2 driver? But what you ideally are hoping for is a dedicated ASIO driver for generic USB2 audio devices, right?
When searching the net New firmware release for USB Audio 2.0 Reference Design | XMOS embedded processors. Heart of XMOS technology, XCore.com, it seems to me that ASIO should atleast be partially supported at the moment, depending on what windows driver you use.
- Status
- Not open for further replies.