[hadron70]

Also changing the input is often not recognized.
I wildly change inputs, users and presets back and forth that somehow I'll get sound on the headphones.

Happened to me as well: A16 failed to recognize the input signal on HDMI 1 (the only source I use), changing input sources back and forth did not help. I have not tried reboot and preset changes.

 

[audiohobbit]

Happens to me all the time.
When I turn on the A16 now I can nearly be 100% sure that at first no sound will come out of the thing. Even for the totally default User B. I have to reload presets and hope that then sound will be played. With my "own" user I created (User A) and use the Surrey PRIRs along with may manLOUD HPEQ it always says "reload" in red letters on the preset page, no matter how often I press enter. It does load the correct preset as it looks but always tell to reload. Does not happen with the factory default B User.
Yesterday I even had speaker maps without any speaker at all in the beginning!
In the Audio meters display you can also see that input sound is there, but no sound over the headphones is coming. So the A16 internally "knows" that it does not play sound over the headphones in these cases.

When the buzzing ocurred again to you what PRIR did you use?

 

[dsperber]

You read my proposal for easier preset selecting??

My suggestion would be: When in speaker map display press enter (because the enter key doesn't do anything in speaker map display I assume) and you get a menu with a list of presets, you navigate to the preset you want, press enter, and it gets loaded.

The list of presets should have the number on the left (with blue or green background depending on user A or B) and the name (or better a name you can assign by yourself!) on the right.

And I would say display max. 4 presets per menu page in bigger letter so that you still can read this from a distance!

I actually disagree that choosing a preset should be visually oriented, depending on being able to see anything on this small LCD screen and navigating the onscreen cursor or selected row/item be it relatively large/bright/contrast or not. I'm not 3-5 feet from the A16, or even 10 feet away. I'm watching TV with my headphones on across the room, and will never be able to see anything on this small screen from that distance.

That's why ergonomically designed remotes, with different keys easily detected "blind" by your fingertips and muscle memory, are how it really should work. Ideally you shouldn't need to look at the A16 screen or even the remote (which unfortunately also doesn't have back-lit buttons). You should just be able to run your thumb over the remote without having to look at it and detect keys by their location, or size, or proximity, or something. Ideally anyway. The A8's P1-P4 were easily detectable for this reason.

At first all those solo buttons seemed so important to you and now you want to reassign them?
I'm against it.

Anyway, I think all those proposals are of no use.

I disagree. And my main concern about solo speakers was that the engraved LS/RS buttons up top don't actually solo the true Ls/Rs speakers in a 5.1 PRIR. They are associated with Lss/Rss which only appear in a 7.1 or higher PRIR. This is definitely non-intuitive, and also not the way the A8's LS/RS buttons work which is to always solo the left/right side speakers, either Ls/Rs or Lss/Rss. If the A16 design were the same we wouldn't need to waste two more keys down in the numeeric pad to user-assign Ls/Rs for side speaker solo in a 5.1 PRIR.

But is there really a need to spend 23 keys of this remote for the speaker solo function? The upper 11 pre-engraved keys allocated to solo speakers are not assignable, but do cover 9.1 speakers + one OH (T) speaker. Doesn't cover the other 6 overhead speakers for Atmos setups but certainly covers ear-level speakers for 5.1/7.1/Atmos rooms. Surely you really shouldn't need but 6 of the numeric keys to solo your remaining 6 overhead speakers in a normal 9.1.6 setup. So we have 6 remaining user-assignable numeric keys. Why not be able to use them for presets (e.g. P1-P6, assigned to keys 1-6, and your six overhead speakers assigned to 7-9 and *-#),

My finger can already find those 12 numeric keys down at the bottom of the remote in the dark, and can distinguish the four rows of three "blind". My "production" use of the A16 (like A8) is simply to turn it on and listen through headphones to some source, either HDTV or disc or streaming (or possibly CD audio). So I just want it to be able to easily pick a proper preset for my source (if they are different, e.g. 5.1 audio vs. 7.1, DTS vs. Dolby, HDMI1 vs. HDMI2 vs. SPDIF, etc.). I'm not soloing, I'm not constantly changing presets, I'm just listening... for hours at a time. So I really just want my power-on/preset-select to be as quick and easy and routine as possible. Dedicated preset buttons (even just 6 of them would satisfy my situation) would be most useful to provide this simplicity of use.

I still think the simplest approach is to just extend the user-assignable nature of the 12 numeric keys to add P1-P16 to the values you can browse through and select. You can set up any of the 12 keys to be whatever you personally want... speaker solo, or preset, or some combination that best works for you. Nothing else changes from how things work today, so no other software changes need to be programmed. If a key has been assigned to speaker solo, then it works exactly as it does today, either for "live" or TEST (music loop). If a key has been assign do preset selection, then it is always for that purpose and is simply non-functional if you happen to be soloing speakers in "live" or TEST.

And this way there is zero onscreen visiblity or navigation needed to select a preset. Your finger simply presses a single key (e.g. 1-6 for P1-P6). Period. It works fine in the dark, and when sitting 15 feet away from the A16. Works just as well if you're sitting 3 feet away from the A16. You don't need to be able to see the screen or read it. You just need "muscle memory" in your fingers to find the 1-6 keys, etc.

 

[audiohobbit]

dsperber:
Sorry, what I meant with this

I think all those proposals are of no use

was that I think we can propose many things to the Smyths, but this will all be futile. At least at this point in time.
(That's the problem when you're not a native speaker, you often don't know how to express yourself)

Let's hope they're working on solving the issues, and implementing some of the missing features. To be honest, I don't even expect that they implement everything from my list of promised but missing features. I don't have high hopes for the web based GUI either. The A8 already has a USB port and in the manual they say it is to control it via PC and this never happened...

So, IF they got my mail (sometimes it seems that my mails don't always are delivered, without a notice from the server, but James did definitely get my other mails earlier), and IF they even read this, what do you think they're thinking, having already a long list of features and issues, and then we send every week new requests for things that are sometimes more cosmetic things like displaying SOLO, MUTE etc.

You're now saying that you don't always SOLO your speakers and even don't look at the display, but when writing your proposal this seemed so important to you... and now it's not.

So I'd say we drop this in favor of more important things . (And we never ever mention anything about face recognition to the Smyths... at least I will not in my mail).

Choosing of presets and inputs is more important than this.
As far as I'm concerned: When I have 6, 8, 10 presets I don't want to remember just a number, I want to have a menu with names beside the numbers so I can see which preset I use.

 

[phoenixdogfan]

dsperber:
Sorry, what I meant with this

was that I think we can propose many things to the Smyths, but this will all be futile. At least at this point in time.
(That's the problem when you're not a native speaker, you often don't know how to express yourself)

Let's hope they're working on solving the issues, and implementing some of the missing features. To be honest, I don't even expect that they implement everything from my list of promised but missing features. I don't have high hopes for the web based GUI either. The A8 already has a USB port and in the manual they say it is to control it via PC and this never happened...

So, IF they got my mail (sometimes it seems that my mails don't always are delivered, without a notice from the server, but James did definitely get my other mails earlier), and IF they even read this, what do you think they're thinking, having already a long list of features and issues, and then we send every week new requests for things that are sometimes more cosmetic things like displaying SOLO, MUTE etc.

You're now saying that you don't always SOLO your speakers and even don't look at the display, but when writing your proposal this seemed so important to you... and now it's not.

So I'd say we drop this in favor of more important things . (And we never ever mention anything about face recognition to the Smyths... at least I will not in my mail).

Choosing of presets and inputs is more important than this.
As far as I'm concerned: When I have 6, 8, 10 presets I don't want to remember just a number, I want to have a menu with names beside the numbers so I can see which preset I use.

IMHO, getting this thing on a web interface should be a top priority. A lot of what I'm reading here re display shortcomings stems from having a 3" x 4" window people are squinting at across their listening rooms. If this thing were controllable the same way everything from Kef Loudspeakers to miniDSP components are controlled and programmed, many if not most of these problems would be readily solvable. AFIK, the last DSP unit I know of that couldn't be controlled in some shape or fashion from a Mac or Windows box was the Behringer 24/96 Ultracurve which retailed for $199 USD in 2008--and I take that back b/c it could be controlled through a midi interface. It's inexcusable that a $4000 DSP component has such stone age interface.

 

[audiohobbit]

First you tell Panasonic that it's inexcusable that their UHD-BD-players can't be controlled via App.
Then you go to Smyth.

 

[Fox1977]

It's been a while now that we haven't heard of any news Head-fier getting their A16 shipped... Last i remember was KS #49, i think....

 

[Sordel]

It's been a while now that we haven't heard of any news Head-fier getting their A16 shipped... Last i remember was KS #49, i think....

It may be that Head-Fiers were over-represented in the first fifty and now we're running into customer numbers whose owners aren't members here. That's only a guess though.

 

[Fox1977]

It may be that Head-Fiers were over-represented in the first fifty and now we're running into customer numbers whose owners aren't members here. That's only a guess though.

That's very possible indeed, and i do hope it is the case ! Since Smyth Research keeps on the silent mode despite their commitment for a weekly update a month and a half ago, guessing is all we can do !

 

[Got the Shakes]

Firmware 1.70 is out:

1) Previously we had identified an occasional glitch with the FPGA router on a very small percentage of units. It now appears that the problem was related to insufficient drive current on the serial port controlling this chip. For rev 1.70 Sep 29 2019 we have made changes to the clocking and increased the drive on the associated logic lines. We can report that with these changes the problem can no longer be reproduced here in the factory. The software traps added to the firmware in rev 1.60 remain as a precaution.

2) When playing CDs or DVDs over HDMI or SPDIF and jumping or transitioning audio tracks, certain players exhibit a momentary audio stutter just as the track begins playing. Since not every player causes this problem, firmware rev 1.70 adds an ‘Auto Mute’ time that can be set manually to mask this artefact as required. This feature is found under SETTINGS>SYSTEM>VOLUME SETTINGS. Users should start at 50ms and increase the time until the stutter is no longer heard as one jumps or transitions tracks. Typically, a setting of 350ms will achieve the desired result.

3) Mixdown to stereo now works independently for both User A and User B.

 

[dsperber]

Firmware 1.70 is out:

2) When playing CDs or DVDs over HDMI or SPDIF and jumping or transitioning audio tracks, certain players exhibit a momentary audio stutter just as the track begins playing. Since not every player causes this problem, firmware rev 1.70 adds an ‘Auto Mute’ time that can be set manually to mask this artefact as required. This feature is found under SETTINGS>SYSTEM>VOLUME SETTINGS. Users should start at 50ms and increase the time until the stutter is no longer heard as one jumps or transitions tracks. Typically, a setting of 350ms will achieve the desired result.

I'm puzzled.

Still using 1.60 firmware, because I wanted to be sure I knew how things were working with their first attempt at fixing this, so that I could evaluate what if any change would occur after upgrading to 1.70 and possibly tweaking this new "Auto Mute" time value. From its description when I see the word "mute" I think "absence of sound". So how can some brief mute period do anything more than possibly mask out the stutter artifact which occurs when the audio begins playing? How does it not therefore also genuinely eliminate that much audio from the start of the track, while therefore at the same time hiding the audible stutter which occurs within that small time slice? Don't we want to hear all of the audio on the track? Why give up another 50-350ms of audio, just because there's an artifact within that brief time which is tied to the A16 and which is what really needs "fixing and eliminating", not hiding by muting?

My setup provides the ability to do a very easy A/B comparison of CD playback:

(a) Oppo BDP-103 -> LPCM via HDMI2-out -> HDMI1-in of A16 -> optical out -> optical in of external DAC -> XLR out to Stax amp/headphone
(b) Oppo BDP-103 -> 48K LPCM via coaxial out -> coaxial in of external DAC -> XLR out to Stax amp/headphone

So (a) is CD via HDMI from BDP-103/LPCM into A16 and then optical into the DAC, and (b) is CD via SPDIF directly into DAC. In both cases the DAC feeds XLR output to the Stax amp/headphone. Both setups involve the identical CD player. All I have to do is hit the INPUT button on the DAC to choose either (a) optical input coming from the A16, or (b) SPDIF input coming directly from the BDP-103.

Again still using 1.60 firmware when I navigate CD tracks using (a) there is of course the now well described tiny "stutter" as the audio begins. There is actually already a brief mute period before that (perhaps 1/2 second?) and then sound appears, which begins with that "stutter". In contrast, when I navigate CD tracks using (b) it plays perfectly! 100% of the track is delivered, and the instant-sound presented at the beginning of the track does not exhibit any stutter.

Does this not clearly imply that there's something not right with how the A16 is handling PCM delivered via HDMI from the BDP-103 because there is this brief mute + "stutter" artifact? In contrast the same PCM delivered via SPDIF directly to the DAC/amp/headphone has no 1/2 second mute, and no follow-on audio stutter artifact needing "blanking" (as a "fix") in order to prevent the stutter from being audible?

What am I missing? Why does Smyth feel that providing a secondary variable-length "mute" to prevent the stutter from being heard, on top of the existing 1/2 sec mute that they reduced the 10-second mute down to with 1.60, that this is a "solution" to the problem? Why does the DAC have zero issue handling the PCM output of the BDP-103 via SPDIF such that 100% of the track audio is delivered with zero stutter, while the A16 has a problem accepting PCM input via HDMI which results in our losing about the first second of every track or following any jump?

I'm clearly not appreciating what they're doing here in 1.70, other than adding a second variable mute period to audibly erase the stutter, thus resulting in an even longer period of loss of track audio than just 1/2 sec.

Didn't their original thought in the README for 1.60 indicate that the problem is tied to the use of the decoder for PCM, when it actually wasn't required and that bypassing it entirely would solve the problem completely? I wonder why they didn't just do this in 1.70?

In other words I think I disagree that the issue stems from the CD player, and is something that's just going to be there if you use that player, no matter HDMI or SPDIF out, and therefore it's not "fixable" in the A16 but requires this muting to just make it inaudible. It's clear from my own BDP-103 test that it's NOT coming from the player, but rather from the processing in the A16 and which doesn't occur if you use the very same CD player and simply bypass the A16.

I think they need to fix something in the A16 to bypass the "problem processing".

 

[audiohobbit]

First, I'm a bit surprised that this next FW came so early after 1.60. Looks like it's mainly because they found the reason fur the buzz?
Second, it's interesting that they also use the word stutter. I did not mention this in my E-Mail to James. So either it is common to use this term, or do they actually read this thread?? (Or did someone send an E-Mail to them using that word?).

Why give up another 50-350ms of audio, just because there's an artifact within that brief time which is tied to the A16 and which is what really needs "fixing and eliminating", not hiding by muting?

My understanding is that it is not another 50-350 ms on top of the 0.5 s (which was just a guess of mine), but that you now can variably set the mute time from 50 to 350 ms. I think it's another workaround until hopefully they sorted the problem out together with MDS.

Does this not clearly imply that there's something not right with how the A16 is handling PCM delivered via HDMI

I agree, because with my Oppo and Yamaha AVR there's no problem either, using HDMI. To be more precise I think it's not a problem of the specific player per se, but the interaction between player and decoder/DAC/whatever. It's comparable to video via HDMI: Player A with projector B (and cable C) may not have a problem, but with projector D (like JVC) or even cable E, will have problems, but could be that Player B with projector D cause no problem, although both players with another projector don't have problems. HDMI is "a B*tch"...

Why does Smyth feel that providing a secondary variable-length "mute" to prevent the stutter from being heard, on top of the existing 1/2 sec mute

As I already said: Where do you read this, that it is a secondary mute on top of the already existing?

However I will test 1.70 and report back in the next days.

 

[sander99]

It's my understanding as well that it is not a secondary mute, but only an option to adapt to your specific situation. By the way: 350ms is not the maximum you can set, but Smyth thinks this would be a setting that typically works.

 

[Juy777]

...it's interesting that they also use the word stutter. I did not mention this in my E-Mail to James. So either it is common to use this term, or do they actually read this thread?? (Or did someone send an E-Mail to them using that word?).

I provided a link to this forum to James when i reported the "BUZZ" issue. So they may actually read it. Given how much work they have to do at the moment brings up doubts though.

 

[audiohobbit]

If they would just communicate only a tiny little bit with us...
We're doing the field testing at the moment and that's ok with me if we get the feeling that we participate a little bit in the development process.

Back in 2017 when I talked to Mike on the High End show and wrote him an e-mail afterwards (in those times when they still answered to mails...) he wrote me back that it's always good to hear from the users and that we probably understand the problems better than they do.

I really don't know what happened.

No updates in KS either, even if promised.

So we can again start to speculate, e.g. they had only about 50 units completed; no more money left for the rest, they go belly up in the next months... etc.