Re: [ubuntu-studio-devel] Audio

[Hank Stanglow]

On 01/15/2017 01:10 PM, Ralf Mardorf wrote:

The clueless user wants the Apple approach, the experienced user wants the 
Linux approach. Both have in common to follow a clear KISS principle. If you 
mix both approaches, the result is crap.
I must agree with Ralf on his assessment. When I first came to Linux is 
had a difficult time understanding what a sound server was let alone why 
there were so many In Linux. Win/Mac users never encounter this concept. 
Even now that I've been using Linux for years I think this new GUI tool 
is overly complicated. Is the user doing audio production with a DAW? 
Then start Jack automatically with sane defaults and bridge ALSA and 
Pulse. Is the user primarily using media players to listen to music and 
watch videos? Default to Pulse. The rest, IMO, would be considered a 
system tweak for advanced users (and should be clearly labeled as such).


That said, I think it is great to have a set-up wizard like this and I 
am delighted to see it happening. Personally, I do all my audio using 
wine-rt and it would be great is there was a setting to automatically 
set this up as well, and I'm sure a lot of users coming from Windows 
would appreciate it.


Keep up the good work.

--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Audio

[eylul]

Ok I think I see better what your objection is. I do fully agree with
keeping the interface as simple as possible.

The main concern i have is that, for the basic user, there is a fine
line between keeping it simple and user getting stuck in presets that
doesn't work for them with no recourse except very advanced solutions
that are not accessible to them. For example the point xruns happen
depends from hardware to hardware (unless I misunderstand). Similarly
the 44.1k vs 48k issue depends on if the user uses more professional
hardware or hobbyist tools to do their work. Then adding cases where
users might have external soundcards (or soundcard like devices) or
those that don't. We simply cannot offer a preset for every possible
case, not without having a giant list, which would be a lot more opaque
and still not cover every case. I mean in an ideal world we would have a
database of devices recognized, and have smart presets that does that,
but we simply do not have resources to do it, not in short term at least.

It is easy for us linux veterans in open source communities to find
writing a startup script from scratch as an easy and straightforward
solution, but believe me that is not the case for a lot of people out
there. :) Allowing the user to tweak the presets with guidance in the UI
is a good solution we can offer. They might not be able to tweak the
settings by themselves and understand but at least when they come to
forums or IRC, there is a place where they can be guided without a lot
of explanation.

What makes it approach useful vs fish and fowl, is in how we execute it.
I do agree that we need to be careful to not overdo with customization
options. I don't think we are there yet with overly complicated. All the
same, I would watch carefully and ask for a lot of feedback from a
variety of users when we put this out in the wild, and what type of
support requests we get, whatever we end up deciding.

I think what you are suggesting is that we are not creating a DAW here
like Cubase or Logic Pro, and I agree, it is not the same approach. I
was curious if there was a commercial software similar to JACK that you
were referring to. The idea here is that jack is part of the audio
setup, rather than something solely used for audio specific software,
which is a different approach.

In terms of Jack MIDI - ALSA MIDI bridges, etc, that is something that
is indispensable for those of us who works regularly with a midi
keyboard regardless of expertise level. It was one of the first things I
had to figure out when creating my own setup. :)

Actually writing this I just realized: The clarification that was
missing until now is that we are not only targeting users who record
audio input in a professional or semi professional studio setup, but
also composers who work with midi (or a mixture of midi and recorded
sound), those who do creative coding with live performances, those who
prepare podcasts. All of which need jack for audio connectivity, but not
necessarily in the same way. :)

Best

Eylul


On 01/16/2017 12:10 AM, Ralf Mardorf wrote:
> On Sun, 15 Jan 2017 22:16:40 +0300, eylul wrote:
>> I'd rather not call inexperienced users, or people who don't have a lot
>> of time to go read "lazy". They are users all the same. Not everybody
>> has to become experts.
> Correct and that's why those users want an easy to use GUI, without
> cryptic options and especially without options that don't make sense at
> all.
>
>> Anyway the solution for such users is profiles (from your suggestion we
>> will have 2 or 3). Ideally a beginner user will not have to create or
>> modify their setup at all.
>>
>> This next level of complexity is for users who need a little bit more
>> customization due to their specific hardware or simply use cases we
>> haven't thought of, yet doing so without having to go to scripting and
>> still with tools to easily make decision. It is also a good place to
>> start understanding the underlying structure for the user who wants to
>> learn more.
> Wrong! This would be a "neither fish nor fowl" strategy. Provide sane
> defaults without options that actually just cause doubts, by those
> using defaults, because they don't understand the details. The clueless
> user wants the Apple approach, the experienced user wants the Linux
> approach. Both have in common to follow a clear KISS principle. If you
> mix both approaches, the result is crap.
>> In terms of commercial solutions UIs you are referring to, can you
>> clarify which products you are thinking of? or if possible at all
>> screenshots would be helpful. While we don't want to copy verbatim
>> design solutions, it is helpful to know what people switching from
>> industry standard commercial software to ubuntustudio would expect to
>> find.
> In regards to sample rate, latency and parallel accessible audio by all
> desktop apps there is no proprietary concept successful that is similar
> to your concept. They follow a completely different 

Re: [ubuntu-studio-devel] Audio

[Ralf Mardorf]

On Sun, 15 Jan 2017 21:59:01 +0300, autumna wrote:
>Alright I'll change the text to being only the sample rate.  

This is what I recommend to do, because nothing else, but jack#s
default 32-bit float matters.

>I was wondering about that 192k, but turns out it was a
>miscommunication. 48k default then. (Just to clarify by the way, the
>values in the mockup are by no means final, or even necessarily
>realistic, my only goal in putting them there is to have a sense of how
>much space and what type of interaction is needed. Thus, while these
>informations on defaults etc help a lot, don't worry that some of them
>might not be accurate. Corrections are appreciated through)  

In regards to space 192000 Hz seems to be the maximum provided by audio
interfaces at the moment.
 
>> It's not my wording, I quoted Audiobus settings. 128 frames isn't the
>> frame size providing the lowest latency, just Audiobus mentions
>> this. I wouldn't add a recommendation, but the information about
>> device load and response/latency/delay is useful, even a default of
>> 256 is useful for a lot of audio tasks, smaller would be better, but
>> with a max of 256 it becomes interesting for e.g. guitar effects and
>> smaller than 256 easily could cause xruns. For anything else 1024
>> might be the better default. 1024 is the default provided by
>> Jack.
>Ok, I am not entirely certain I understand this one to revise the
>design.
>* Am I understanding you correctly that frame/cycle doesn't affect the
>latency? In that case we just need to correct the text. Just me know
>what it needs to say  

No, you misunderstand my words, frames affect the latency. Audio
interfaces could work at less than 128 frames, at e.g. 64 frames.
<= 256 frames, IOW <= 10 ms are required to use the computer as
guitar effect processor. Stand alone gear should provide a latency of
around <= 5 ms, but actually at around 10 ms they could already be
usable. values much > 10 ms are more or less unusable for this task. ...

>*  We should steer the users toward 2 values, 256 and 1024. Rather than
>256 default, with 128 and 512 there as other solutions. Do I understand
>that correctly?  

... Yes. The default value provided by jack is 1024 frames, > 40 ms.
This ensures that quasi all audio devices will work without xruns, as
long as there are no serious issues, such as fishy hardware and
unfavourable shared IRQs. Even if the audio devices shouldn't provide
zero latency hardware monitoring, a user might have an analog mixing
console or doesn't need to monitor at all. Not all kinds of audio
production require low latency, even not music production.

A user most likely will use the lowest frame value, IOW the lowest
latency. Actually there's no value we really could recommend, because
this depends much on the used hardware.

The jack defaults provided by the jack manpage are more or less safe
values. In short, jack's default is 1024 frames, but for many tasks a
max of 256 frames is required.

Now another issue. If you take a look at QjackCtl you'll see the
rounded calculated values for the in + out latency at a given frames
value, but related to the used hardware and software, the latency could
be higher than the mathematical value. It doesn't matter that much, you
could mention both, frames as well as the round trip latency.

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Meeting Jan 17 19:30 UTC

[eylul]

There will be a meeting this week, even if it is a quick check-in.

Jan 17, 19:30 UTC
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntustudio+meeting=20170117T1930=1


16.04.2 is coming up soon, and we have other updates I believe. :) If
you have an update you want to add but can't make to the meeting, feel
free to add to this thread.

Best

Eylul


-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Audio

[eylul]

I'd rather not call inexperienced users, or people who don't have a lot
of time to go read "lazy". They are users all the same. Not everybody
has to become experts.

Anyway the solution for such users is profiles (from your suggestion we
will have 2 or 3). Ideally a beginner user will not have to create or
modify their setup at all.

This next level of complexity is for users who need a little bit more
customization due to their specific hardware or simply use cases we
haven't thought of, yet doing so without having to go to scripting and
still with tools to easily make decision. It is also a good place to
start understanding the underlying structure for the user who wants to
learn more.

In terms of commercial solutions UIs you are referring to, can you
clarify which products you are thinking of? or if possible at all
screenshots would be helpful. While we don't want to copy verbatim
design solutions, it is helpful to know what people switching from
industry standard commercial software to ubuntustudio would expect to find.

Best

Eylul


On 01/15/2017 08:14 PM, Ralf Mardorf wrote:
> On Sun, 15 Jan 2017 17:22:12 +0100, Dennis Schulmeister-Zimolong wrote:
>> Hi Ralf,
>>
>> On Sun, 15 Jan 2017 16:56:52 +0100
>> Ralf Mardorf  wrote:
>>
>>> For experienced audio users and novices willing to learn your app is
>>> crap. The target group are users who don't have a clue and who are
>>> unwilling to learn. You need to make it easy for them, but actually
>>> you make it harder, by mixing jack settings, with settings that are
>>> not directly related to jack and by providing the same choice jack
>>> provides. Don't!
>>>
>>> Provide a first choice, 1. music production, 2. other
>>> audio productions (radio etc.) and 3. audio for anything else. Don't
>>> provide to chose between PA bridge and things like this. Disable PA
>>> for music production and enable it for other audio productions and
>>> don't launch Jack at all, for anything else.  
>> I can't help but find your answer here unfair and biased. All in all I
>> think the proposed UI really helps to make things easier, not only for
>> people who are "too lazy to learn the details" and options like ALSA
>> MIDI or PA bridge are not as unreasonable as you think. They are
>> options anyway.
>>
>> I agree with you on the 32-bit bit depth setting. Other than that I
>> like the proposed UI much better than what you are suggesting here. In
>> fact your proposal is an even more "dumb" UI. What's the difference
>> between music and audio production anyway? Where do you know from, that
>> I don't also need low-latency in an audio production context? Or that I
>> don't need to listen to some web-audio on my monitor speakers while
>> working on a new song? You don't, and that's why the original proposal
>> gives me the choice to enable the features I want, while striping away
>> some of the more obscure jack parameters.
>>
>> Dennis
>>
> Hi,
>
> the available options require some additional short information, but
> apart from this, noob-friendly GUIs provided by the most successful
> proprietary platforms work the way as I suggested. If expert
> options are needed, then this app makes no sense at all, especially in
> regards to low latency, there's a lot more to take into account.
> Btw. before writing an application, it's most important to have a clear
> idea about what it should provide and for what purpose it should be
> provided. To conceptualize when already writing the app is the ultimate
> guarantor that "you" or somebody else ask yourself "how does you know,
> what I need?". Asking this questions actually means, that at best you
> know what you need, but maybe you even don't know this, but you
> definitively don't care about a target group, for an app that should
> provide settings, that are fundamental part of the distro.
>
> If you keep the other options as are, then you could also provide a
> selection of bit depth. Some combinations, for some tasks and for some
> target groups simply don't make sense. The "how do you know?" question
> is part of a concept.
>
> When producing music, it makes not much sense to listen to web radio at
> the same time. If you produce web radio, it could make sense for
> comparison purpose, hence "Provide a first choice, 1. music production,
> 2. other audio productions (radio etc.) and 3. audio for anything
> else". Apart from the pre selected pulseaudio or no pulsaudio, the used
> frames could still be chosen, so in this regards latency isn't
> affected. If you really want to fine tune, optimize latency, then start
> with building a rt patched kernel, unbind devices, stop unneeded
> services ...
>
> Regards,
> Ralf
>



-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Audio

[autumna]

I was only gone for dinner. :D

First of all, a reminder to everyone to please remember being
constructive rather than negative as it was the case in this email.

While I know Ralf enough to not take the tone of his email personally, I
have already heard from several people that this is the type of
conversation that keeps happening in the mailing list that discourages
them from participating. This is bad for the productivity, morale and
sustainability of the whole group.

Nobody in this team is experts on all topics, nor should there be
assumptions that it is a requirement to be eligible to participate. As
we discuss, there will be mistakes, there will be misunderstanding,
there will be lack of knowledge, and even differences in opinion. We
have designers, audio experts, programmers, packagers and learners here.
Nobody knows everything, so we need each others contributions and
support to make Ubuntustudio better.

Also just to clarify, this is not my application, nor Len's. This is a
blueprint that has been in our todo list for a while. Len has been
putting a lot of work into making it happen. I have been trying to on
and off (and not nearly as much as I'd like to) put effort on UI design
aspect of it. Not everything will be functional at once, and some things
might take several cycles of feedback, not just brainstorming from us
but also from our users. Software takes time to mature. However, it is
important to have feedback early and often, which is why this
conversation in this mailing list has been happening on this topic and
will keep happening instead of waiting until a finished program.

Alright enough of this, onward to replies.


On 01/15/2017 06:56 PM, Ralf Mardorf wrote:
> Hi Eylul,
>
> Jack is a sound server for audio production purpose. For good reasons it
> defaults to 32-bit float. There's nearly no good reason to decide
> against this default. The bit depth used by the sound server has
> nothing to do with e.g. CD compatibility.
>
> If this app should make setting up an audio environment easier for
> noobs, only offer to select between all available sample rates and
> don't provide any choice to change the bit depth at all.

Alright I'll change the text to being only the sample rate.

>
> The default sample rate should be 48000 Hz. Sometimes it could make
> sense to chose 44100 Hz, so maybe you could recommend both. Other
> sample rates seldom make sense. Anyway, all sample rates should be
> provided, but selecting another bit rate instead of 32-bit float very
> unlikely is useful for anybody using averaged x86 or x86_64, aka amd64
> hardware and common Linux audio apps.
I was wondering about that 192k, but turns out it was a
miscommunication. 48k default then. (Just to clarify by the way, the
values in the mockup are by no means final, or even necessarily
realistic, my only goal in putting them there is to have a sense of how
much space and what type of interaction is needed. Thus, while these
informations on defaults etc help a lot, don't worry that some of them
might not be accurate. Corrections are appreciated through)

>> I added your wording with one difference (using latency instead of
>> response) but happy to change that back if need be. That option can be
>> more verbose too, but will require a bit of a layout tweak in that
>> case.
> It's not my wording, I quoted Audiobus settings. 128 frames isn't the
> frame size providing the lowest latency, just Audiobus mentions this. I
> wouldn't add a recommendation, but the information about device load and
> response/latency/delay is useful, even a default of 256 is useful for a
> lot of audio tasks, smaller would be better, but with a max of 256 it
> becomes interesting for e.g. guitar effects and smaller than 256
> easily could cause xruns. For anything else 1024 might be the better
> default. 1024 is the default provided by Jack.
Ok, I am not entirely certain I understand this one to revise the design.
* Am I understanding you correctly that frame/cycle doesn't affect the
latency? In that case we just need to correct the text. Just me know
what it needs to say
*  We should steer the users toward 2 values, 256 and 1024. Rather than
256 default, with 128 and 512 there as other solutions. Do I understand
that correctly?
> For experienced audio users and novices willing to learn your app is
> crap. The target group are users who don't have a clue and who are
> unwilling to learn. You need to make it easy for them, but actually you
> make it harder, by mixing jack settings, with settings that are not
> directly related to jack and by providing the same choice jack
> provides. Don't!
>
> Provide a first choice, 1. music production, 2. other
> audio productions (radio etc.) and 3. audio for anything else. Don't
> provide to chose between PA bridge and things like this. Disable PA for
> music production and enable it for other audio productions and don't
> launch Jack at all, for anything else.
>
> Everybody understanding the terms and/or 

Re: [ubuntu-studio-devel] Audio

[Ralf Mardorf]

On Sun, 15 Jan 2017 17:22:12 +0100, Dennis Schulmeister-Zimolong wrote:
>Hi Ralf,
>
>On Sun, 15 Jan 2017 16:56:52 +0100
>Ralf Mardorf  wrote:
>
>> For experienced audio users and novices willing to learn your app is
>> crap. The target group are users who don't have a clue and who are
>> unwilling to learn. You need to make it easy for them, but actually
>> you make it harder, by mixing jack settings, with settings that are
>> not directly related to jack and by providing the same choice jack
>> provides. Don't!
>> 
>> Provide a first choice, 1. music production, 2. other
>> audio productions (radio etc.) and 3. audio for anything else. Don't
>> provide to chose between PA bridge and things like this. Disable PA
>> for music production and enable it for other audio productions and
>> don't launch Jack at all, for anything else.  
>
>I can't help but find your answer here unfair and biased. All in all I
>think the proposed UI really helps to make things easier, not only for
>people who are "too lazy to learn the details" and options like ALSA
>MIDI or PA bridge are not as unreasonable as you think. They are
>options anyway.
>
>I agree with you on the 32-bit bit depth setting. Other than that I
>like the proposed UI much better than what you are suggesting here. In
>fact your proposal is an even more "dumb" UI. What's the difference
>between music and audio production anyway? Where do you know from, that
>I don't also need low-latency in an audio production context? Or that I
>don't need to listen to some web-audio on my monitor speakers while
>working on a new song? You don't, and that's why the original proposal
>gives me the choice to enable the features I want, while striping away
>some of the more obscure jack parameters.
>
>Dennis
>

Hi,

the available options require some additional short information, but
apart from this, noob-friendly GUIs provided by the most successful
proprietary platforms work the way as I suggested. If expert
options are needed, then this app makes no sense at all, especially in
regards to low latency, there's a lot more to take into account.
Btw. before writing an application, it's most important to have a clear
idea about what it should provide and for what purpose it should be
provided. To conceptualize when already writing the app is the ultimate
guarantor that "you" or somebody else ask yourself "how does you know,
what I need?". Asking this questions actually means, that at best you
know what you need, but maybe you even don't know this, but you
definitively don't care about a target group, for an app that should
provide settings, that are fundamental part of the distro.

If you keep the other options as are, then you could also provide a
selection of bit depth. Some combinations, for some tasks and for some
target groups simply don't make sense. The "how do you know?" question
is part of a concept.

When producing music, it makes not much sense to listen to web radio at
the same time. If you produce web radio, it could make sense for
comparison purpose, hence "Provide a first choice, 1. music production,
2. other audio productions (radio etc.) and 3. audio for anything
else". Apart from the pre selected pulseaudio or no pulsaudio, the used
frames could still be chosen, so in this regards latency isn't
affected. If you really want to fine tune, optimize latency, then start
with building a rt patched kernel, unbind devices, stop unneeded
services ...

Regards,
Ralf

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Audio

[Dennis Schulmeister-Zimolong]

Hi Ralf,

On Sun, 15 Jan 2017 16:56:52 +0100
Ralf Mardorf  wrote:

> For experienced audio users and novices willing to learn your app is
> crap. The target group are users who don't have a clue and who are
> unwilling to learn. You need to make it easy for them, but actually
> you make it harder, by mixing jack settings, with settings that are
> not directly related to jack and by providing the same choice jack
> provides. Don't!
> 
> Provide a first choice, 1. music production, 2. other
> audio productions (radio etc.) and 3. audio for anything else. Don't
> provide to chose between PA bridge and things like this. Disable PA
> for music production and enable it for other audio productions and
> don't launch Jack at all, for anything else.

I can't help but find your answer here unfair and biased. All in all I
think the proposed UI really helps to make things easier, not only for
people who are "too lazy to learn the details" and options like ALSA
MIDI or PA bridge are not as unreasonable as you think. They are
options anyway.

I agree with you on the 32-bit bit depth setting. Other than that I
like the proposed UI much better than what you are suggesting here. In
fact your proposal is an even more "dumb" UI. What's the difference
between music and audio production anyway? Where do you know from, that
I don't also need low-latency in an audio production context? Or that I
don't need to listen to some web-audio on my monitor speakers while
working on a new song? You don't, and that's why the original proposal
gives me the choice to enable the features I want, while striping away
some of the more obscure jack parameters.

Dennis

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel