I don't know how to put this, an Apple Audio HW bug?

Hi guys and gals...

Apologies for any typos...

Well I have a major problem and I don't know how to take it further so I need your advice AND help...
Found from the AudioScope.sh calibration method(s)...

I think I have found a HW bug in Apple gear...

This has been checked so far on a new iPhone 5S,
a 3 month old iPad Air and my Macbook Pro...

As a confirmation I have tried it on my old Blackberry Phone, Windows Vista and XP on various machines
Debian Linux and PCLinuxOS 2009 on an HP laptop and an Acer Aspire One netbook these work perfectly as
the sound _card_ should...
It has even been checked as a RAW file in /dev/dsp too and is correct.
(Will check CygWin tomorrow.)

Consider the code below:-
It was written to set up the vertical amplifier polarity and works as designed BUT........

#!/bin/bash --posix
> /tmp/pulse.wav
printf "\x52\x49\x46\x46\x24\x00\x01\x00\x57\x41\x56\x45\x66\x6d\x74\x20\x10\x00\x00\x00\x01\x00\x01\x00\x40\x1f\x00\x00\x40\x1f\x00\x00\x01\x00\x08\x00\x64\x61\x74\x61\x00\x00\x01\x00" >> /tmp/pulse.wav
for n in {0..8191}
do
	printf "\xFF\xFF\x00\x00\x00\x00\x00\x00" >> /tmp/pulse.wav
done
afplay /tmp/pulse.wav
exit 0

This works perfectly on the RANDOM gear as it should; a NEGATIVE going pulse NOT a POSITIVE one.
When pulse.wav is transferred to run on the Apple gear above the waveform is inverted, I.E. it is a
POSITIVE going pilse. AFAIK this is wrong.

What I would dearly like is for the interested on here to check the waveform from the earphone socket
against a known Oscilloscope and reply to this thread.

You can test on anything that plays a .WAV file. The quality of the wave is NOT important the polarity
IS however...

It should look something like this:-

 =-+  +-----------+  +-------  <- 0x00 Unsigned 8 bit.
   |  |           |  |
   |  |           |  |
   |  |           |  |
   |  |           |  |
   +--+           +--+  <- 0xFF Unsigned 8 bit.

Remember quality is NOT important, polarity IS...

I will be checking on other machines and phones myself over the WE...

Many thanks in advance...

NOTE:- I have not yet posted anywhere else and hope I am wrong. thanks guys and gals...

If this is consitent throughout Apple gear then I don't know how to take it further...

Barry.

EDIT:
Many thanks to my workmate Richard Carter for letting me test on his iPhone 5S and
his iPad Air...

It could be anything from the software implementation of the player and codecs, its DSP chipset, or the output amplifier which causes the inversion. It really doesn't matter for audio purposes, since it sounds the same. You're just seeing the relative popularity of different designs, not "right" or "wrong".

By which I mean, I don't think you can count on it always being the same, you'll need a way to invert it.

[edit] Actually, you could put a switch in your circuit to invert, couldn't you? To flip the secondary side of the transformer.

By the way, I think you can build that file in 8179 fewer loops.

printf "\x52\x49\x46\x46\x24\x00\x01\x00\x57\x41\x56\x45\x66\x6d\x74\x20\x10\x00\x00\x00\x01\x00\x01\x00\x40\x1f\x00\x00\x40\x1f\x00\x00\x01\x00\x08\x00\x64\x61\x74\x61\x00\x00\x01\x00" > /tmp/pulse.wav
printf "\xFF\xFF\x00\x00\x00\x00\x00\x00" | tee -a /tmp/pulse.wav > /tmp/0.wav
# File size doubles every loop
for ((N=0; N<13; N++))
do
        # The - causes it to print the data twice.
        tee -a /tmp/pulse.wav - < /tmp/0.wav > /tmp/1.wav
        mv /tmp/1.wav /tmp/0.wav
done

rm /tmp/0.wav

Hi Corona688...
I could also use this:-

#!/bin/bash --posix
> /tmp/pulse.wav
data="\xFF\xFF\x00\x00\x00\x00\x00\x00"
printf "\x52\x49\x46\x46\x24\x00\x01\x00\x57\x41\x56\x45\x66\x6d\x74\x20\x10\x00\x00\x00\x01\x00\x01\x00\x40\x1f\x00\x00\x40\x1f\x00\x00\x01\x00\x08\x00\x64\x61\x74\x61\x00\x00\x01\x00" >> /tmp/pulse.wav
for n in {0..12}
do
	data=$data$data
done
printf "$data" >> /tmp/pulse.wav
afplay /tmp/pulse.wav
exit 0

But my point is that .WAV, .RAW, (.AIFF??), are definitive and have been for decades.

Heck even the AMIGA follows the same course although signed 8 bit data; that is a high
number translates to a low signal point and vice versa.

Why is the Apple gear quoted different? Deliberate, accidental or maybe unaware?

The .WAV and .RAW formats are good for signal generation and that is why I used them
albeit 8 bit unsigned MONO...

Modifying the AudioScope.sh code is easy but I should not have to allow for it...

Oh well I'll put it down to experience and plod on...

I will try CygWin today and in /dev/dsp mode...

Hi Corona688...

Absolutely except I have since found a Windows machine that does the same as the Apple gear.
The problem is that this now changes the goalposts as CygWin follows the host Windows OS and the HW it is on.
So therefore one will never know whether the single pulse generator is correct or not SO......

Now I have to assume that the person(s) experimenting with the script do(es) NOT have access to a (semi-)professional oscilloscope but DO have access to a simple multimeter.

So generate two versions of the pulse generator, one '+ve' going and the other '-ve' going named pulse1.wav and pulse2.wav respectively.
Using CCT 3, the voltage doubler, connect the multimeter across the DC output and run each one in turn. The lower voltage one will be +ve going and vice versa.

In fact the Arduino access is already a voltmeter so even a multimeter is not a requirement...

Neat eh! ;o)

Version 0.30.xx to be released soon...

Hmm, if the voltage doubler has current enough to drive a small LED, the multimeter might not be necessary. One signal would light, and the inverted one would not.

It would have to be buffered, of course, or the signal would "float" up to whatever point averages out to zero volts because of the capacitor in the way.

And if it's buffered/amplified, why not use it to drive the LED directly?

Hi Corona688...

Indeed. Leave it with me I already have a test piece I built years ago for my AMIGA so with a little jiggery pokery will see how it progresses... ;o)

Also just received this baby ready for Raspberry Pi, (Raspian):-

Sound Blaster Play! External USB Sound Card - Creative Labs (Asia)

Works out of the box on Linux Mint...
Yup, you guessed it I am going to attempt to include RP too! <Shock horror.>

It defaults to /dev/dsp and /dev/audio so gives me basic access.

Dunno if SOX installs/compiles on RP yet but at least /dev/dsp is a possibility...
Will know in the next few days... ;o)

I like these little computers. Beagleboard is the brand I ended up using. Full-fledged enough to compile its own programs. If you can do that on RP, that's worth the effort and extra space IMO, much less throwing files around and version mismatch problems update problems etc etc etc.