Recommended control points

[lejonklou]

The control point can be regarded as the source of Källa's output signal and there are some musical quality differences between different models. We have tested various control points and will continue testing more models as we get the opportunity. Forum members are encouraged to add to the list by stating for instance "I found X more musical than Y". This will provide only a relative difference and thus not an absolute position, but over time the relative differences will combine into a fuller picture.

While at first we attempted to give each control point a score, we soon found it difficult as the scale had to repeatedly be revised. So I felt that just listing them from best to worst makes more sense. The musical differences between two control points that are next to one another is small, sometimes negligible, while if you compare the top position with the bottom position, the difference can be significant.

The reason behind these musical differences are mostly unknown. When WiFi is used, they might be related to the model of the modem chip in the device. Most conditions seem to have close to zero influence on musicality, such as CPU power, other programs running (maxing out CPU load with calculations excluded), flight mode enabled or disabled, etc. So it doesn't matter if you are using the control point to do other things, like surfing for information about the artist, while the music is playing.

I recommend having a stationary and dedicated control point for Källa, because if you are using your personal phone, the music will pause if you leave the house or if you get a phone call (notification sounds will however not be heard or cause any interrupts). If you are listening by yourself this may not matter, but if you are listening together with others, it's much nicer if the music being played is accessible on a control point easily accessible and shared by all.

It should be noted that in the list below, the size of the RAM memory likely doesn’t affect musical performance. We still specify it, to let you know which specific unit was tested.

[lejonklou]

Control point musicality, from best to worst (list will be continually updated):

Tied top three:
• iPad mini 6 64GB
• iPhone 16 Pro Max 256GB
• iPhone 14 Pro Max 512GB

Other tested devices (top ones are close to the above three in musical performance):
• iPhone 15 Pro 256GB and iPhone 15 Pro Max 512GB (these two sound identical)
• iPhone 11 128GB
• iPad Pro 12.9" M2 cellular (using WiFi)
• MacBook Pro 16” M1 Max 32GB unified (connected with cable)
• MacBook Pro 16” M1 Max 32GB unified (using WiFi)
• iPhone 14 Pro Max 256GB
• MacBook Pro 16" i9 (connected with cable)
• iPad Pro gen3 11" M1 (connected with cable)
• iPad Pro gen3 11" M1
• iPhone 14 Pro
• iPhone 13 Pro Max
• iPhone 12 Pro Max
• iPhone 6+
• iPhone 8+
• MacBook Pro 16" i9 (using WiFi)
• Mac Mini 2015 (using WiFi)
• iPad Pro 11"
• iPad Pro 10.5"
• iPad mini 1
• iPad mini 5
• iPhone 12 mini
• iPhone 6S

Updated 2024-10-29

[matthias]

Control point musicality, from best to worst (list will be continually updated):

Thanks Fredrik,

May I assume all iPhones and iPads were used via WiFi?
Any idea why iPhones seem to be superior to iPads?

Matt

[lejonklou]

May I assume all iPhones and iPads were used via WiFi?
Any idea why iPhones seem to be superior to iPads?

Yes, if it doesn't say anything, it's using WiFi.

It's interesting to note that the iPhone 11 (using wifi) and the computer connected to the WiFi router with a cable are extremely close to one another in performance. They are both in a league of their own, with an extreme timing and raw nerve on every track. That's why I added an empty line between them and the next group.

No, I don't know why the iPads tested so far haven't been as good as the iPhone 11. I bought an iPad mini 5 in the hope that it would sound great, because I really like the size of it. I might trade it for some other iPad model, there are many left to test.

[donuk]

I am aware that I take a different stance on some matters hifi on this Forum, which is one reason it fascinates me.

I will just throw in a couple of observations which might have some bearing on this discussion.

My experience suggests that the success of streaming in general depends very much on what happens to files as they travel from adjacent equipment to the streamer or Airport express or DAC or whatever.

There are quite a lot of things that can be done in the home environment to improve the way digital files get to waggle speaker cones.

The thing that struck me about the discussion on this thread is a possible similarity with a discussion and experiments friends of mine conducted concerning the unlikely subject of the relative sound of control apps, typically on iPads, via wifi. Typically Kazoo, Linn White app, Lumin and its spinoffs. There is a body of opinion that these can affect the sound of the music. Of course we know all they do is to transfer a playlist to the memory of a streamer and adjust a few things like volume and track progress. Which of course causes extra traffic on the network. (Obviously the iPad can be switched off and traffic reduced.) Kazoo is thought to be poor in this respect.

But this fits in with my own findings - that almost however you reduce traffic and noise on a network the better the file will sound.
Taking the hifi part of the network out of the DHCP range reduces the tireless pinging that goes on with constant address allocation and confirmation. A noisy process. Fixing addresses also helps.

I have also now got opto coupling to my Melco S100 switch which causes a massive improvement. And we know from this forum that cheap SMPSs that typically power switches and opto converters are also bad news.

A lot to chew on here. I share it only in the thought that it may have some relevance to the undoubted excellence of the new Freddie-Digi-Box. I accept it might be a minority view.

Donuk rainy downtown York

[teatime]

Taking the hifi part of the network out of the DHCP range reduces the tireless pinging that goes on with constant address allocation and confirmation. A noisy process. Fixing addresses also helps.

Helps what? And how?

DHCP:
Client: Can anyone give me an IP address?
Server: Sure, I can.
Client: Cool, can I have one?
Server: Here you go. It's yours for <lease time>

The above is exchanged using UDP packages (the same protocol as is used to transfer RTP, which (I assume) is the audio transfer protocol used by Källa). The exchange most likely requires only one packet per message and is reasonably over in less than a second.

Lease time can vary, but the standard appears to be 24h. Wikipedia suggests it is common that a renegotiation is done when half the lease time has passed - meaning every 12h. The renegotiation is done towards the same DHCP server, so it doesn't require the discovery phase - meaning it requires less messages.

DHCP is not "noisy". It's a handful of UDP packets every 12h, for a second or so.

Dynamic Host Configuration Protocol
DHCP Client/Server Interaction

[lejonklou]

I agree with your findings, Donuk. Reducing the traffic on a network where a streamer is receiving data packets and converting them to music can influence the quality of the conversion process.

But this effect depends a lot on how the streamer works and exactly what it's doing on the network. Most streamers are doing a lot of things other than receiving packets of musical data and this affects how and when those packets are received, which in turn affect the quality of the conversion to analogue music.

A key feature of Källa is that it's been designed to receive the musical data in a precise and optimised manner, do the few necessary additional tasks exactly when they have no influence on the conversion process and then do nothing additional. This is why it doesn't speak UPnP and chatter with your NAS. And this is why general network traffic doesn't bother it. The result is that it doesn't sound at all digital.

[lejonklou]

DHCP is not "noisy". It's a handful of UDP packets every 12h, for a second or so.

Yes, that is how it's supposed to work. Still, assigning Källa with a fixed IP address instead of DHCP removes a small but easily heard "digital signature" in the music. Not once every 12 hours but all the time.

There is a huge amount of such small details that have been optimised in Källa's interaction with the network, but this is the only one left for the user to control. As standard it's set to DHCP, you can choose to give it a fixed IP and listen whether you hear any improvement.

[teatime]

Yes, that is how it's supposed to work. Still, assigning Källa with a fixed IP address instead of DHCP removes a small but easily heard "digital signature" in the music. Not once every 12 hours but all the time.

Do you have any explanation for how this can possibly be? It seems to defy understanding.

mDNS is reasonably far noisier in terms of number and frequency of messages, and I doubt you can turn that off, or Källa won't be found on the network. (Or?)

[teatime]

Yes, that is how it's supposed to work. Still, assigning Källa with a fixed IP address instead of DHCP removes a small but easily heard "digital signature" in the music. Not once every 12 hours but all the time.

Do you have any explanation for how this can possibly be? It seems to defy understanding.

Ok.. I actually have one myself. Not an "explanation", but at least an actual difference between DHCP and fixed IP: There needs to be something on the system to keep track of the lease time and trigger a new negotiation. Older Linux distributions (which is what I assume the Tinkerboard part of Källa runs) usually used a dedicated daemon process (these days it's typically done by systemd-networkd, which does more than DHCP). This process should spend most of the time asleep (it only needs to wake up often enough to understand that time passes), but it is there and running.

IF this can affect the system to a degree that it's audible, that could explain the difference. But that is technically not related to network traffic.

And I still wonder if mDNS isn't a worse problem.

[lejonklou]

Ok.. I actually have one myself. Not an "explanation", but at least an actual difference between DHCP and fixed IP: There needs to be something on the system to keep track of the lease time and trigger a new negotiation. Older Linux distributions (which is what I assume the Tinkerboard part of Källa runs) usually used a dedicated daemon process (these days it's typically done by systemd-networkd, which does more than DHCP). This process should spend most of the time asleep (it only needs to wake up often enough to understand that time passes), but it is there and running.

Yes, I think you are correct in this.

[tokenbrit]

Ok.. I actually have one myself. Not an "explanation", but at least an actual difference between DHCP and fixed IP: There needs to be something on the system to keep track of the lease time and trigger a new negotiation. Older Linux distributions (which is what I assume the Tinkerboard part of Källa runs) usually used a dedicated daemon process (these days it's typically done by systemd-networkd, which does more than DHCP). This process should spend most of the time asleep (it only needs to wake up often enough to understand that time passes), but it is there and running.

Yes, I think you are correct in this.

Is there a difference in musicality between configuring a fixed IP on Källa*, or reserving a static IP for Källa on the router?

* assuming this is possible

[teatime]

Ok.. I actually have one myself. Not an "explanation", but at least an actual difference between DHCP and fixed IP: There needs to be something on the system to keep track of the lease time and trigger a new negotiation. Older Linux distributions (which is what I assume the Tinkerboard part of Källa runs) usually used a dedicated daemon process (these days it's typically done by systemd-networkd, which does more than DHCP). This process should spend most of the time asleep (it only needs to wake up often enough to understand that time passes), but it is there and running.

Yes, I think you are correct in this.

Is there a difference in musicality between configuring a fixed IP on Källa*, or reserving a static IP for Källa on the router?

* assuming this is possible

I obviously haven't heard Källa, but working from the assumption that a running DHCP client process on Källa lessens the performance, the answer is yes.

Källa can't tell the difference between a dynamically allocated IP address that happens to be statically assigned on the router and one that isn't. It will still have to run the DHCP client process to negotiate the address, even if it always comes back the same.

With a fixed IP on Källa (apparently possible, since we're talking about it...) it doesn't have to run this process at all.

[lejonklou]

Exactly right, teatime.

[tokenbrit]

Thanks both.
I'm curious if there are advantages to configuring fixed IPs on other audio network devices as well, including control points...

[donuk]

Tokenbrit


Yes. Try your NAS.
Fix your address on it as well as your router.
Also it will prevent playlists which hold absolute addresses becoming useless.

Donuk wet downtown York

[tokenbrit]

Tokenbrit


Yes. Try your NAS.
Fix your address on it as well as your router.
Also it will prevent playlists which hold absolute addresses becoming useless.

Donuk wet downtown York

On it, Don. Just trying not to take Källa posts off topic... Will be interested to read the preferred setup and config to get the absolute best from Källa, but aware there may be benefits from applying to other devices too ;)

[lejonklou]

We have made a major breakthrough in the control point department.

The musical differences between them are now virtually nonexistent!

This happened after a week of tuning all the network parameters in Protokoll. We arrived at a new combination of optimal values that sound more fluid and relaxed than the original configuration. As an unexpected bonus, this also removed close to 100% of the differences between control points.

We have just now compared six control points;
MacBook Pro 16" i9 connected with cable
iPhone 11
iPhone 12 Pro Max
iPad Pro 10.5"
iPad mini 1
iPad mini 5

The ranking order is no longer easy to determine. MacBook connected with cable to the router is perhaps a tiny step above the others, but the difference feels unimportant. The iPad mini 5 is perhaps still at the bottom of this list, but the difference is not really a musical one. It's rather that it sounds a little less energetic.

A clear indication of the unimportance of the control point is that after the comparison, we listened to the music that Spotify chose based on the last song I had played. And we listened for a good while, just being immersed in and enjoying every song. Eventually I said "Hey, which unit is active?" - with so many on the table it wasn't easy to know - and it turned out to be the iPad mini 5. Not once had we felt something was missing.

I feel so happy about this!

[beck]

Congratulation Fredrik! I can easily understand your feelings. :-)

What a great discovery!

[matthias]

The musical differences between them are now virtually nonexistent!
I feel so happy about this!

REALLY GREAT,
congrats :-)

Matt

[ThomasOK]

Congratulations! That is indeed very cool. Can't complain about better musical perfromance and improved flexibility. Since an iPad Mini makes a pretty ideal control point (compact size but still big enough to easily read and see artwork) that is very handy. It is what we use in the store for control for those reasons. I want my Källa!

[Spannko]

We have made a major breakthrough in the control point department.

The musical differences between them are now virtually nonexistent!

This happened after a week of tuning all the network parameters in Protokoll. We arrived at a new combination of optimal values that sound more fluid and relaxed than the original configuration. As an unexpected bonus, this also removed close to 100% of the differences between control points.

We have just now compared six control points;
MacBook Pro 16" i9 connected with cable
iPhone 11
iPhone 12 Pro Max
iPad Pro 10.5"
iPad mini 1
iPad mini 5

The ranking order is no longer easy to determine. MacBook connected with cable to the router is perhaps a tiny step above the others, but the difference feels unimportant. The iPad mini 5 is perhaps still at the bottom of this list, but the difference is not really a musical one. It's rather that it sounds a little less energetic.

A clear indication of the unimportance of the control point is that after the comparison, we listened to the music that Spotify chose based on the last song I had played. And we listened for a good while, just being immersed in and enjoying every song. Eventually I said "Hey, which unit is active?" - with so many on the table it wasn't easy to know - and it turned out to be the iPad mini 5. Not once had we felt something was missing.

I feel so happy about this!

That’s a really interesting discovery. Have you any thoughts on why the control points initially had an effect and why they no longer do?

[Fred11]

Great news and good work! Congrats
F

[lejonklou]

Thank you all!

That’s a really interesting discovery. Have you any thoughts on why the control points initially had an effect and why they no longer do?

We don't understand this completely, but network parameters all have a range in which they work. Too low or too high values cause problems. Even before the problems begin, you can hear the "stresses" they cause when the values are getting extreme but the data still transfers reliably. Electronically I'm unsure of exactly what is happening, as I can't measure what happens in the modem circuits of the control points.

It seems that when we evaluated combinations by just listening for the most musical result, we ended up with values that make the modem circuits work in a relaxed and fluid way. Apparently that makes them behave more equally. I bet there are some electrical parameters that could shed further light on this, if I only had direct access to (and adequate understanding of) those modem circuits.

The router doesn't influence these parameters at all, by the way. We used three different ones, from new mesh to old models, and ended up with exactly the same optimal parameters.

[Spannko]

Thank you all!

That’s a really interesting discovery. Have you any thoughts on why the control points initially had an effect and why they no longer do?

We don't understand this completely, but network parameters all have a range in which they work. Too low or too high values cause problems. Even before the problems begin, you can hear the "stresses" they cause when the values are getting extreme but the data still transfers reliably. Electronically I'm unsure of exactly what is happening, as I can't measure what happens in the modem circuits of the control points.

It seems that when we evaluated combinations by just listening for the most musical result, we ended up with values that make the modem circuits work in a relaxed and fluid way. Apparently that makes them behave more equally. I bet there are some electrical parameters that could shed further light on this, if I only had direct access to (and adequate understanding of) those modem circuits.

The router doesn't influence these parameters at all, by the way. We used three different ones, from new mesh to old models, and ended up with exactly the same optimal parameters.

That sounds even more interesting than I initially thought! Well done, it appears to be quite a significant breakthrough.

What are “modem circuits of the control points”?