Jump to content
IGNORED

Contracting for a custom Linux driver


joelha

Recommended Posts

I'm doubting they're going to give me the specs, mansr, although I could ask.

 

What do you think it would take in money and/or in time to get the driver I needed if they handed over the specs?

 

And what do you think it would take in money and/or in time to reverse engineer the driver from the Windows/Mac driver?

 

Thanks so much for all your help.

 

Joel

 

Oh dear, that sounds like a big problem. When you were first asking about the PUC2 LIte, I had a quick look at the Yellowtec web site. On this page:

 

Yellowtec: PUC2 Lite

 

It says:

 

"..There are no drivers to install.."

 

And so I thought it must be some kind of Linux setup problem. But reading it a bit more carefully they might mean that the drivers for Mac OS X or Windows are installed when you plug the unit in, and "no drivers to install' actually means "no manual install of drivers needed".

System (i): Stack Audio Link > 2Qute+MCRU psu; Gyrodec/SME V/Hana SL/EAT E-Glo Petit/Magnum Dynalab FT101A) > PrimaLuna Evo 100 amp > Klipsch RP-600M/REL T5x subs

System (ii): Allo USB Signature > Bel Canto uLink+AQVOX psu > Chord Hugo > APPJ EL34 > Tandy LX5/REL Tzero v3 subs

System (iii) KEF LS50W/KEF R400b subs

 

Link to comment
I'm doubting they're going to give me the specs, mansr, although I could ask.

 

What do you think it would take in money and/or in time to get the driver I needed if they handed over the specs?

 

And what do you think it would take in money and/or in time to reverse engineer the driver from the Windows/Mac driver?

 

Thanks so much for all your help.

 

Joel

 

I'm thinking you'll want to have the manufacturer's permission, so the "specs" and "reverse engineering" routes may look pretty similar.

One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> optical Ethernet to Fitlet3 -> Fibbr Alpha Optical USB -> iFi NEO iDSD DAC -> Apollon Audio 1ET400A Mini (Purifi based) -> Vandersteen 3A Signature.

Link to comment
I'm thinking you'll want to have the manufacturer's permission, so the "specs" and "reverse engineering" routes may look pretty similar.

 

If you get the specs (assuming they even exist), it will save you the reverse engineering step. Should they refuse, there's no need to get permission to reverse engineer the protocol. People do that all the time.

Link to comment
Should they refuse, there's no need to get permission to reverse engineer the protocol. People do that all the time.

 

Now you're dispensing legal advice? I've been an attorney for over 35 years and have been involved in a couple of intellectual property litigations (a long time ago), and I would not presume to give legal advice in a forum such as this. But go right ahead....

One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> optical Ethernet to Fitlet3 -> Fibbr Alpha Optical USB -> iFi NEO iDSD DAC -> Apollon Audio 1ET400A Mini (Purifi based) -> Vandersteen 3A Signature.

Link to comment
Now you're dispensing legal advice? I've been an attorney for over 35 years and have been involved in a couple of intellectual property litigations (a long time ago), and I would not presume to give legal advice in a forum such as this. But go right ahead....

 

I'm just stating the indisputable fact that people reverse engineer hardware interfaces all the time with no consequences whatsoever other than the occasional job offer. If you were to build a clone of the hardware, you might get in trouble, but I have never heard of anything bad resulting from merely writing a driver.

Link to comment
If you get the specs (assuming they even exist), it will save you the reverse engineering step. Should they refuse, there's no need to get permission to reverse engineer the protocol. People do that all the time.

 

Thanks a lot, mansr. I can ask.

 

What do you think it would cost to take either route, given that I'm not capable of doing the work myself?

 

Joel

Link to comment
Right, except the problem is that this is the best device I've ever used so for me, at least at this time, there isn't a substitute.

 

More or less than $1,000 would you guess?

 

Best case, you get specs and it turns out to be very similar to something already supported (that actually happens fairly often), $1000 might get it done. If reverse engineering is required, I wouldn't expect less than $10k.

Link to comment
  • 2 weeks later...

Hi there,

 

I have some good news.

 

2 months ago I was actively in research of a good USB/ AES adaptator for my system (between PC and DEQ2496). I read a lot on it and the PUC2 lite was often recommended, the bad point is itsn't compatible with my Daphile computer, but you already knows it. I decided to contact directly yellowtech, and they answer me to have no troubles with their ubuntu test. As I didn't possess the PUC2 so I cannot answer anything to this. And I just follow another project (First One amp.), I read today your thread with interest and communicate it to my previous yellowtech contact. After a support request from the vendor (they do not actively support linux up to now) I got the following statements which explains the behavior and makes things clearly understandable:

The Firmware of PUC2 tries to identify what kind of OS is attached to it. E.g. is it a MAC or is it a Windows PC?

 

 

The reason for this identification is that Windows supports only USB Audio Class 1 with sample rates up to 48 kHz. However, MAC supports USB Audio class 2 which means sample rates up to 192 kHz.

Additionally, if you install the drivers (for MAC or Windows) you can use the vendor mode as described in the thread and everything is available.

 

If the device discovers a MAC OS, the Firmware starts with USB Audio class 2 mode where all sample frequencies are supported up to 192 kHz.

If it discovers that the OS is Windows, it starts with USB Audio class 1 mode and supports only the 48 kHz you mentioned.

 

Now attaching on linux, it seems like the Device thinks that if a linux OS is connected it is a Windows OS. The point is that there is NO protocol definition which can be used to answer that question about which OS is attached. We do this by a trick which I will not mention here. But the trick doesn’t work obviously for Linux.

 

However, there might be a solution if we would provide a special firmware which has no detection of the OS but works fine in USB Audio class mode 2 only. This version would work fine without drivers for Linux and MAC but not for Windows.

 

It has to be clarified at the beginning of next year if this change could be simply done by a firmware update or if it needs more. If it’s just a firmware update, it could be soon available.

 

 

This is good news, and we can also very appreciate the kindness of the customer/technical service of yellowtech.

To be continued...

Link to comment

The Firmware of PUC2 tries to identify what kind of OS is attached to it. E.g. is it a MAC or is it a Windows PC?

 

 

The reason for this identification is that Windows supports only USB Audio Class 1 with sample rates up to 48 kHz. However, MAC supports USB Audio class 2 which means sample rates up to 192 kHz.

Additionally, if you install the drivers (for MAC or Windows) you can use the vendor mode as described in the thread and everything is available.

 

If the device discovers a MAC OS, the Firmware starts with USB Audio class 2 mode where all sample frequencies are supported up to 192 kHz.

If it discovers that the OS is Windows, it starts with USB Audio class 1 mode and supports only the 48 kHz you mentioned.

 

Now attaching on linux, it seems like the Device thinks that if a linux OS is connected it is a Windows OS. The point is that there is NO protocol definition which can be used to answer that question about which OS is attached. We do this by a trick which I will not mention here. But the trick doesn’t work obviously for Linux.

 

Interesting/evil approach. If only they'd divulge how they detect the OS, it might be possible to make Linux emulate the Mac behaviour and trigger the USB Audio class 2 mode. Still, this is more helpful than I would have dared to expect. Please keep us posted.

Link to comment
  • 5 weeks later...

Hi, I've planned to contact again Yellowtech next monday, it seems correct. Since my last post I've purchased a PUC2 (no lite) so I'm completely in "the boat" with you ;). I use a Teradak TeraLink to power the PUC with a bypass usb cable, I can't quantify the improvement, my system is completely changing since the last months (new apartment, addition of a digital equalizer (DEQ2496) which is temporarily my DAC also) and I'm planning a new amp and a new DAC. But, I just can say on some active auditions I discover new details on some well-knows tracks.

So the addition of the PUC between my PC and my equalizer with AES/EBU connection (but I'm waiting a true 110 ohm raw cable for DIY, I'm using a mic cable), in front of a direct (PC->equalizer) toslink connection, is clearly better, but I suppose that the DAC of the DEQ2496 is restricting the improvement.

With no surprises, Daphile use it well, but with the max 48khz sample freq. I keep in touch with you .

Link to comment

Sorry for reacting so late. For the kind of info needed on page 1 of this thread, I created the `alsa-capabilities` script, which --with a single command-- shows what formats and sample rates each alsa device supports.

 

All you have to do is copy and paste the following in a terminal and press ENTER:

bash <(wget -q -O - "http://lacocina.nl/alsa-capabilities") -s

 

More information can be found on:

 

Regards,

Ronald

Link to comment
Sorry for reacting so late. For the kind of info needed on page 1 of this thread, I created the `alsa-capabilities` script, which --with a single command-- shows what formats and sample rates each alsa device supports.

 

All you have to do is copy and paste the following in a terminal and press ENTER:

bash <(wget -q -O - "http://lacocina.nl/alsa-capabilities") -s

 

I strongly discourage sending random web pages directly into a shell. It doesn't even take malicious intent for things to go horribly wrong if you do. See for example https://www.seancassidy.me/dont-pipe-to-your-shell.html

Link to comment
I strongly discourage sending random web pages directly into a shell. It doesn't even take malicious intent for things to go horribly wrong if you do.[/url]

 

Thanks for stipulating the importance of secure behaviour when it comes to dealing with 'things from the net'. However, I've complete control over the source and distribution, and the `alsa-capabilities` script itself really does nothing else than a lot of string manipulation. So even in the case of a partial download, that would lead to (cryptic) errors, but would cause no harm.

 

Observe the difference to my instructions for (securely) getting and running the parent script, `mpd-configure`.

Link to comment
Thanks for stipulating the importance of secure behaviour when it comes to dealing with 'things from the net'. However, I've complete control over the source and distribution,

 

Your website might get hacked. You might forget to renew the domain. You might decide to abandon the domain. Since the link is HTTP, not HTTPS, someone could intercept and alter the data. There are numerous ways the data served by that link could end being something you didn't intend.

 

and the `alsa-capabilities` script itself really does nothing else than a lot of string manipulation.

 

How are we to know that without downloading it first? If it really did something nefarious, you probably would say so.

Link to comment

Dear manser,

 

Your website might get hacked. You might forget to renew the domain. You might decide to abandon the domain.

 

Although that hasn't happened for the last 14 years, of course it (theoretically) could.

 

Since the link is HTTP, not HTTPS, someone could intercept and alter the data. There are numerous ways the data served by that link could end being something you didn't intend.

 

Right again. That can happen, too, theoretically. Like it could be that the instructions you are providing are somehow not genuine or "nefarious", for example because this website got hacked beacuse it runs on unpatched PHP libraries.

 

How are we to know that without downloading it first? If it really did something nefarious, you probably would say so.

 

The script is intended for people who are not familiair with audio on linux, and system management in general (eg do not know what you mean when you instruct them to "run something as root"). That's a much bigger security concern (for those users) then the stuff you're warning against. As is running closed or binary firmware.

 

Those that are familiair with such things, probably first download and inspect the script, or scan the internet for its origin.

 

So again, I understand your primary concern and thank you for expressing that. But the script and my instruction to run it are just meant to help you, Adam, Joel and others to get to the important stuff (in this case getting an overview of device support in alsa) a bit quicker.

 

Regards,

Ronald

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...