Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Bluetooth delay (Score 1) 141

You're right, it's part of the process and I shouldn't have neglected it. But I think it's not the main reason for the delay.
Just keep in mind that there is more than that, especially in the case of a car (that I don't know everything about), but also in a BT speaker (which I know much more because it's part of my job).

Comment Re:Bluetooth delay (Score 1) 141

There are many potential causes for the delay. And they can add a second here, few ms there. I guess that :
- there is the button on your wheel that goes through the car wiring and base embedded system : can (and CAN !) take time.
- the button event is communicated to the infotainment system : should be fast, but who knows ?
- the infotainment system sends an AVRCP (play, stop, pause, next/previous track) command through its Bluetooth module : some of these can also take time. I had the case where play was immediate, but pause (same play/pause command in fact) took 3 seconds. By the way, next/previous may be used in two way : short press (for track change) or long press (for fast forward/backward). May be your car system waits a bit to know of its a short or a long press.
- your phone receives the command and propagates it to the music player : depending on the music player, there may be some fading delay. Check your player settings !

By the way, may I ask how this topic is related to the initial post (cURL) ? Oh, yes, the mail example ... A bit light may be ...

Comment Qt (Score 1) 133

I'm already using Qt and am happy to stay away from the painful VS.
- under Windows, Qt uses gcc/MinGW (or VS compiler if you wish)
- under Mac OS X, Qt uses XCode compiler
- under Linux, Qt uses native and easily installed gcc

At the time of the version 3, I also had the opportunity to work with the embedded version (user interface in trains, running on PPC computers).

So there is Qt, and there are many other solutions described in the other comments. M$, what are you doing here, then ?

By the way, since Skype is made using Qt : M$, please, explain why there are so many differences between versions, especially with the Linux one ? Need some lessons in portability ?

Comment Re:Here's the problem with stereo Bluetooth: (Score 5, Informative) 385

To add details to your answer : first point, look at your source : is it FLAC or MP3 (or any equivalent). If the source is bad, it cannot be better at the other end.

AFAIK, Bluetooth uses an A2DP pipe and this pipe allows the transmission of data using 4 codecs :
- SBC : the first historically, the worst in quality
- AAC
- MP3
- aptX

SBC, AAC and MP3 are lossy codecs. I never saw a product that accept AAC or MP3. There must be a license to pay to use MP3; may be also for AAC.
aptX is both lossy and lossless. And most source devices (smartphones, computers ...) are aptX ready.

So, the technology already here to allow a much better quality than what we know (as long as one can force the use of the lossless variant of aptX, which is ... well, you know ... Obfuscated to say the least).

Then what ?
Then CSR : the dominating Bluetooth chips manufacturer. More than 70% of the chips last time I heard.
CSR has patents on aptX.
And patents are meant to make money (yes; were you told otherwise ?).

So, the sink devices (BT speakers, car audio systems, ...) are aptX ready only if the manufacturer paid CSR. I'm not sure, may be $1 per product. That's a lot compared to the rest of the BOM. A BT speaker you pay $150 cost less than half when leaving the Chinese factory.

And guess what : manufacturers like profit, so they don't pay CSR for aptX and stick to SBC.
The hardware is always ready, the firmware may contain the aptX codec, but if the license key, linked to the BT MAC address of the chip, is not present in the firmware, aptX won't be negotiated as an available codec with the source device. Only SBC will be used, even if your source device can do aptX.

By the way, if you like your music, listen to it on real speakers in your living room !

Comment Re:So many features I will never use ... (Score 1) 286

I have written template, but I can't remember when. I may write templates again, but I'm not looking forward to it. There are so many other solutions.

However, I'm using containers, based on templates. Mostly those of Qt, rarely now those from the STL. That does not make my code not clumsy, nor not error-prone. You won't believe it, I do make error, whatever the language is ! Yes !

I was just telling that, in my opinion, using template can makes my code look complex, obscured, hard to understand after 2 weeks, just as if I wrote it in Perl. And understanding compiler error messages, sometimes just because of a typo, can be a pain in the ass.

Part of the problem is that I know nobody who ever read the C++ specifications, and I'm among those people. I could, but it would get me fired, because I've better things to do during the day, and I sleeping most of the night.
I live for coding, but it cannot be my unique activity. And when I do code, my purpose is not to try to use all the old and new features of the language. My purpose is to make it work in a readable form, by me or may be later, by others. Others that can also be part of the problem (as I could judge, many of the colleague I worked with were not fit for such language; how lucky I am now, I'm the only C++ programmer in my current small team !).

Comment Re:Latency (Score 1) 94

Mac OS X supports aptX. I've done the test :
- connect to an aptX capable speaker
- alt-clic the Bluetooth menu
- menu shows more details about the connection. Among them, it showed the used codec : aptX when it's used (SBC in most other cases).

The market is pretty bad in my opinion :

- CSR (owned by Qualcomm now, as you said) makes most of the sold chips. Perhaps something like 70%. But something you'd learn only after buying one of their expensive development kit is that the chip is based on a very old architecture, the ADK (SDK for CSR chips) is awful, resources are sparse. Some examples :
        - to build your application, you either start from scratch (just crazy) or use a provided example. You'll get something like 100 or 150 bytes of free memory for your data. Good luck optimizing the base code to get more.
        - sizeof(uint8) = 2. Yes. As crazy as it sounds, it is allowed by the C/C++ specifications. But that's the only time and the only platform on which I saw such a crazy thing. It may be justified by the old chip architecture (may be there's only even addresses, you can only reach pairs of bytes). But CSR does not advertise this, you have to guess by yourself and struggle with strange behaviors. CSR likes to waste your time. unit8 a = 255; a ++; a == 256. Deal with that.
        - the only I2C function available allows you to transfer data from the chip to a slave. Very well ? Not really. First point, how do you think the data is transferred from your buffer when sizeof(uint8) = 2 ? Just try, it's not documented. Second point, the documentation (I should say the comment in the .h) says that you'll probably encounter radio problems (sound cuts) if you try to transfer more than 64 bytes. Wrong, you'll discover that it should say : you cannot transfer more than 64 bytes, period.
        - how would you discover that ? By using the CSR support ? How long would it take ? Hours ? Days ? No, weeks. If you are a small structure, don't hope for a responsive support. It took us around 1 month to get an answer to a question, and we had many. You must be Bose or UE or something to get a true support I guess. You'll buy 50 K - 100 K chips per year ? Not interested.
        - the build firmware can use virtual filesystem. It works, but for an unknown reason, you'll can only use the first 3 KB of your files. There's a workaround, but that's 3 KB at a time.
        - the DSP part of the chip, Kalimba, has good performances on paper (80 MIPS I think). But its fixed point calculations. When you were using an ADAU1701, with floating point calculation, you fall from high. I could have known by reading the CSR chip datasheet ? May be. May be not.

- Microchip : they bought ISSR after trying to buy CSR. They could be a solid competitor to CSR, but I don't know anything about any SDK. They have some very low latency solutions, using the BT radio, but no BT protocol at all, just some proprietary one.

- Chinese manufacturer. I only know they exists. I did not even think about asking for datasheets or SDK ...

- English solution providers. There are some, with a good experience of CSR chips (they are all from Cambridge, the C in CSR). But they are very expensive.

Slashdot Top Deals

Always look over your shoulder because everyone is watching and plotting against you.

Working...