IanCanada's Latest RPi GB Goodies Impressions... and your tweaks, mods and hints...

1)
IMO what you ask for is not technically possible for AirPlay/iTunes.

It IS possible because that is exactly the behavior that happens with iTunes playing to any of the Naim Uniti devices via airplay.

iTunes (or remote app) volume changes are shown on the uniti display just like they are shown on Ian's controller display.

But changes to the Naim volume knob or Naim remote also are reflected as changes to the volume sliders in iTunes and also the iTunes remote app.

It is bi-directional, I can make a video of people are interested.

Also the album art and details of the track playing are also sent to the uniti for display.

Now I can believe that shairport doesn't have that capability since they are reverse engineering the protocol and don't have all the details. I was just hoping for similar behavior to this commercial product.

sheldon
 
stokessd: The reversed-engineered protocol is what the open-source authors have to work with. That is why what you ask for is not possible, unless there is a known way to pass the info back. Do you know about any? If so, you can ask/motivate the software authors to implement the feedback. Or implement it yourself.

If the feedback API is not known, it is not possible, as simple as that.
 
stokessd: The reversed-engineered protocol is what the open-source authors have to work with. That is why what you ask for is not possible, unless there is a known way to pass the info back. Do you know about any? If so, you can ask/motivate the software authors to implement the feedback. Or implement it yourself.

If the feedback API is not known, it is not possible, as simple as that.


I know, but my point was that at the end of the day, no matter what I do with hardware attached to a Pi or any other linux based SBC, I'll never get the same sort of functionality that I currently have and enjoy. I have no issues buying another Uniti, but I wanted to scratch my building itch.

This is a classic Linux problem. I've been using it as a hobby and professionally since 2002, and it's always half-baked. Some things are great and solid, but there is always some Achilles heal that makes it a non-starter. After nearly two decades, I am still a mac and windows guy who longs for the old days of my old Sun workstation. I still use it on servers and for very specific tasks, but this is a classic case of me wanting to love it and it being lacking.


Sheldon
 
How is it linux devs' fault that apple has neither released any specs nor provided a pre-compiled airplay library for linux? You insist on using a commercial proprietary software - complain with the company you pay your money to.

I don't believe I ever said it was anybodies fault. I merely pointed out that I was disappointed at the lack of functionality that I have grown accustomed to.
 
still waiting for my kit for Ian, but gathering parts already. Yesterday received the NDK clocks. Those are f* small how the hell are you guys soldering those to adapters ? Any hints welcome ..

Easy if you have two soldering irons:

0. Add flux before all soldering steps below.
1. Tape down the adapter using scorch tape. Tin the 4 solder pads on the adapter.
2. Add flux to the bottom of the NDK chip.
3. Place the chip into position. Align the small dot for pin 1.
4. Heat all 4 pads simultaneously (why two irons are needed).
5. The melted solder should drag the chip into correct position due to surface tension.

Works for me although I used hot tweezers but the steps are the same.
 
Small tip for your iron, tweezers and headband type magnifying glass helps me work on small SM stuff. I also have probes with really fine tips to connect to my meter, I always ohm my work out to make sure I have a good connection.
Tips are something like these (I didn't get mine here, don't remember where they came from) Needles, Picks, Probes, Pin Vise, Holders, Dissection Tools
 
additional hints

Agree with all from Jacklee. I also lay down a white cotton cloth over the work surface. Makes it easier to see the little devil, and if you drop it, it is less likely to bounce off the table and never be found again.
Also, make sure you have a strong magnifying glass like a jeweler's loupe to read the etching on the case to get correct orientation.
Also buy some really good needle nose tweezers. I find the ones with a 45 degree bend at the tip makes it easier to place these little parts. Don't squeeze to hard or the part will fly out end up lost on the floor.
See Greg's hint about marking one corner with a sharpie so you can tell you place it in correct orientation.
 
Agree with randytsuch on checking the connection. I only checked it visually using a magnifying glass but before I put it into the fifo board I had second thought - if any one of the tiny cap solder pads have a short then it may not end well with the battery supply.

I ended up testing the clock using a lab DC supply with current limiting and a scope before actually using them. Without that it would be prudent to check for short between VCC and GND *before* soldering the clock (not sure if it is safe to check continuity with the clock in place, may need to check your meter's output voltage just to be safe).
 
Agree with randytsuch on checking the connection. I only checked it visually using a magnifying glass but before I put it into the fifo board I had second thought - if any one of the tiny cap solder pads have a short then it may not end well with the battery supply.

I ended up testing the clock using a lab DC supply with current limiting and a scope before actually using them. Without that it would be prudent to check for short between VCC and GND *before* soldering the clock (not sure if it is safe to check continuity with the clock in place, may need to check your meter's output voltage just to be safe).

I used these tiny ndk clocks in one project, and checked continuity after installed, and they worked fine after. I use a fluke dmm for most measurements, not sure what voltage it applies when it measures resistance.
From what I remember, you need to be careful not to bridge to case, which will create a short to ground.

I ALWAYS check for shorts from VCC to ground before I apply power to a project, and this would be even more important if using a battery. Working with batteries is basically working with a live power supply that can supply a TON of instantaneous current. I've not blown anything so far, but have made some pretty good sparks when connecting batteries to projects.

Randy
 
okay thx for little hints, I have all of the stuff you guys were recommending on hand. The main issue is age with 50+ those SMD parts are really not my favourits to solder. I have done a few SMD chips in the past and they all worked ;)

lol. Yeah I think after you pass 45 or so, parts get smaller every year.
 
Member
Joined 2009
Paid Member
Software tip wanted

I intend to do some output measurements (THD, noise etc.) using a couple of different power schemes, DAC HATs and I/V stages.
To do so I guess I can of course just 'play' some audio files with defined test-tones, but it would really be much more convenient and smart if some sort of function generator could be installed on the RPi.
What do you fellows do?
Or do you 'just' listen to music? :eek:
 
I've made my own WAV files years ago to make pure tones. I was using them for breaking in woofers and such, but you could use the same code to make wave files of any length and frequency with the following code:

Sheldon


// Wav file generator 1.0
// This program generates a sine wave of any frequency and duration
//
// Sheldon D. Stokes
// December 3, 2003
//
// note (dec 29, 2015): with 64 bit os's like receint OSX, compile like: cc wave_gen.c -m32
// long and short are now 8 and 4 bytes long in 64 bit os's
//

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include<math.h>
#define samplerate 44100.0
#define amplitude 30000.0
#define pi 3.14159265359
//#define swap 1

// swap is defined when running on a big-edian machine EI Mac, comment out for a PC


void swapshort(short *);
void swaplong(long *);

int main(int argc, char* argv[])
{

char outpath[255];
float freq,len,ang;
long int totbytes,longtemp,i,j,phase;
short int shorttemp,buff[2*44100];
FILE *filept;


// get input parameters

printf("Frequency of sine wave (Hz): ");
scanf(" %f", &freq);
printf("\n");

printf("Duration of sine wave (sec): ");
scanf(" %f", &len);
printf("\n");

printf("Output File Path (example: c:\\temp\\temp.wav): ");
scanf(" %s", outpath);
printf("\n");


// open file for writing

filept = fopen(outpath,"wb");

// write riff header

fprintf(filept,"RIFF");

totbytes = len * samplerate * 4.0; // total length of data
totbytes = totbytes + 24 + 8; // extra bytes from data header and data head

#ifdef swap
swaplong(&totbytes);
#endif
fwrite(&totbytes,sizeof(long),1,filept);

fprintf(filept,"WAVE");

// write format chunk

fprintf(filept,"fmt ");

longtemp = 0x10; // size of format
#ifdef swap
swaplong(&longtemp);
#endif
fwrite(&longtemp,sizeof(long),1,filept);

shorttemp = 0x01; //always ??
#ifdef swap
swapshort(&shorttemp);
#endif
fwrite(&shorttemp,sizeof(short),1,filept);

shorttemp = 0x02; //num of chans stereo=2
#ifdef swap
swapshort(&shorttemp);
#endif
fwrite(&shorttemp,sizeof(short),1,filept);

longtemp = samplerate; //sample rate
#ifdef swap
swaplong(&longtemp);
#endif
fwrite(&longtemp,sizeof(long),1,filept);

longtemp = samplerate*4; //bytes per second
#ifdef swap
swaplong(&longtemp);
#endif
fwrite(&longtemp,sizeof(long),1,filept);

shorttemp = 4; //bytes per sample stereo 16 bit = 4
#ifdef swap
swapshort(&shorttemp);
#endif
fwrite(&shorttemp,sizeof(short),1,filept);

shorttemp = 16; //bits per sample
#ifdef swap
swapshort(&shorttemp);
#endif
fwrite(&shorttemp,sizeof(short),1,filept);

// write data


fprintf(filept,"data"); // data header
longtemp = samplerate*4*len; //length of data to follow
#ifdef swap
swaplong(&longtemp);
#endif
fwrite(&longtemp,sizeof(long),1,filept);

phase = 0; // init to random phase
ang = 2.0*pi * freq /(samplerate);
for (j=0;j<len;j++){
for (i=0;i<samplerate;i++)
{
buff[i*2] = amplitude * sin(ang*phase);
#ifdef swap
swapshort(&buff[i*2]);
#endif
buff[i*2+1] = buff[i*2];
phase++;
}
fwrite(buff,sizeof(short),samplerate*2,filept);
}

// close file

fclose(filept);


return 0;
}

void swapshort (short *ch)
{
char *cp,tempc;


cp=(char *)ch;
tempc=cp[0];
cp[0]=cp[1];
cp[1]=tempc;
}


void swaplong (long *ch)
{
char *cp,tempc;

cp=(char *)ch;
tempc=cp[0];
cp[0]=cp[3];
cp[3]=tempc;

tempc=cp[1];
cp[1]=cp[2];
cp[2]=tempc;
}
 
D

Deleted member 537459

Hi all!
Fifopi complete is arrive!!
The result is amazing sound thanks Ian.
I have some question, i use dietpi with roon bridge, in spund card option i install ess9028k2m and work but in option of roon i can choose 64bit and is limt to dsd 128. The sistem when go to 352khz no work, sound come but i have many noise.
What sound card option you install on dietpi? Thanks for all answer.
 
D

Deleted member 537459

I am thinking of an alternative opamp for the IV converter.
The discrete types look promising.

The opamps I have found so far:

1) burson audio
2) sparko labs
3) Dexa


Reading some reviews I tend to prefer the sparko labs.

Please note that I use an amplifier and speaker system that is extremely resolving; an opamp with little body and too much analytics will make the sound balance tip over to cold and tiring, so an opamp with nice colours and some warmth is preferred.


Is there anybody with listening experience with these opamps? Are there other alternatives?

regards,

I try burson v6 vivid v6 classic and sparkos, i prefer burson v6 vivid because is more real, the sparkos have good sound but make all tiny. Burson is realy nice! My question is, the mercury teasted pear is the best choice or i/v with very nice opamp is similar result?