Bug 42654

The percent value doesn't mean anything serious, so you can't compare it at all.
Check the dB level and compare with the value represented in Windows, if any.

Of course, it's a different question whether you get the higher max value.
It's possible that some hardware provide higher in Windows by some extra amp feature that's not turned on as default.

(In reply to comment #1)
> The percent value doesn't mean anything serious, so you can't compare it at
> all.
> Check the dB level and compare with the value represented in Windows, if any.
> 
> Of course, it's a different question whether you get the higher max value.
> It's possible that some hardware provide higher in Windows by some extra amp
> feature that's not turned on as default.

When I set maximum volume, Windows is also much much louder and there's no amplification of any kind enabled (I've checked everything I could) - I use Microsoft supplied drivers (I don't have RealTek drivers installed).

In fact both Windows XP with RealTek drivers (no special mixer settings whatsoever) and Windows 7 with "Microsoft" drivers are several times louder.

Realtek offers some Linux drivers on their website - are those just repackaged ALSA drivers? Is it worth poking their support so that they looked into this issue?

The exact same problem:

http://forums.gentoo.org/viewtopic-t-892626-start-0.html (Sound is too quiet)

Strangely there are no more reports on this problem, I guess it's because few people really use Linux.

I've played with HDA Analyzer a bit and I've found out that changing Node[0x02] AUD_OUT Output Amplifier from its default value 21 to 64 (or maybe to any other higher values - I cannot say for sure) makes volume comparable to Windows.

Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out
  Device: name="ALC892 Analog", type="Audio", device=0
  Control: name="Front Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=1, idx=0, ofs=0
  Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
  Amp-Out vals: [0x14 0x15]
  Converter: stream=8, channel=0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power: setting=D0, actual=D0

Are you sure that you adjusted both "Front" and "Master" volumes?  "Front" should be 0dB (100%), and then "Master" would be the volume you want.  If you set both to 0dB, DAC 0x02 should reach to the same value as you tested.

In short, try like:
    amixer -c0 set Front 0dB
    amixer -c0 set Master 0dB

If the problem persists with the setup above, give alsa-info.sh snapshot after running these commands.

try toggle eapd


Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Control: name="Headphone Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0001373e: IN OUT HP EAPD Detect Trigger
    Vref caps: HIZ 50 GRD 80 100
  EAPD 0x2: EAPD
  Pin Default 0x02214c20: [Jack] HP Out at Ext Front
    Conn = 1/8, Color = Green
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0xc0: OUT HP VREF_HIZ
  Unsolicited: tag=04, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c 0x0d 0x0e 0x0f 0x26*

(In reply to Raymond from comment #7)
> try toggle eapd

I'm sorry how I can do that?

It's done in hda-analyzer (wget -O run.py http://www.alsa-project.org/hda-analyzer.py)

I cannot toggle it - it looks to be read-only.

Any other ideas? There are two dozen of nodes, and for instance Node [0x0b] AUD_MIX has 20 scrolling controls - all muted.

Maybe there's a tool to dump HDA codec parameters in Windows so that I could compare?

The same with ALC269VB. The maximum volume in Windows is much louder, perhaps even twice.

This only seem to happen with the speakers, not with headphones, or HDMI audio.

And EAPD seems to be enabled here.

Artem, did you read the comment 6?

Felipe, your problem is likely different, especially if it happens only with the speaker.  Create a separate bug report, and attach alsa-info.sh output there (run it with --no-upload option).

(In reply to Takashi Iwai from comment #12)

> Felipe, your problem is likely different, especially if it happens only with
> the speaker.  Create a separate bug report, and attach alsa-info.sh output
> there (run it with --no-upload option).

I said it _seemed_ to happen only with speakers, but I'm not sure. Anyway, here's the report: bug #62651.

(In reply to Felipe Contreras from comment #13)
> (In reply to Takashi Iwai from comment #12)
> 
> > Felipe, your problem is likely different, especially if it happens only
> with
> > the speaker.  Create a separate bug report, and attach alsa-info.sh output
> > there (run it with --no-upload option).
> 
> I said it _seemed_ to happen only with speakers, but I'm not sure. Anyway,
> here's the report: bug #62651.

Then double-check it :)  We need the fact.

(In reply to Takashi Iwai from comment #6)
> Are you sure that you adjusted both "Front" and "Master" volumes?  "Front"
> should be 0dB (100%), and then "Master" would be the volume you want.  If
> you set both to 0dB, DAC 0x02 should reach to the same value as you tested.
> 
> In short, try like:
>     amixer -c0 set Front 0dB
>     amixer -c0 set Master 0dB
> 
> If the problem persists with the setup above, give alsa-info.sh snapshot
> after running these commands.

Nah, doesn't help:

[birdie@localhost ~]$ amixer -c0 set Front 0dB
Simple mixer control 'Front',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 64
  Mono:
  Front Left: Playback 64 [100%] [0.00dB] [on]
  Front Right: Playback 64 [100%] [0.00dB] [on]

[birdie@localhost ~]$ amixer -c0 set Master 0dB
Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 64
  Mono: Playback 64 [100%] [0.00dB] [on]

And the requested information?

(In reply to Takashi Iwai from comment #16)
> And the requested information?

Next time I'll cold boot.

Funnily if I reboot to Linux after running Windows, the volume levels are correct (i.e. maximum volume matches the one in Windows).

It seems like Windows uses some magic to initialize the HDA codec, and then a subsequent Linux boot works just fine.

Created attachment 110681 [details]
alsa-info.txt (boot after Windows, maximum volume - correct(loud))

Good to know that.  I guess Windows sets some COEF for the amps.

But, to make it clear, could you take alsa-info.sh output at the state with the max volume but still too soft (i.e. not after Windows boot)?
The first alsa-info output attached doesn't match with the last one, thus we can't compare exactly.

Created attachment 115101 [details]
GUI volume vs alsa-mixer volume

It's a bug with alsa-lib. See the attached screenshot.

In short - what ALSA internally represents as e.g. 28% it exports as 50% volume.

So, what GUI mixers, including ALSA's own graphical equalizer, show as 50% is what I have as 28% in Windows (and internally in ALSA).

I will keep this bug open until the bug in alsa-lib is fixed.

Comparing in percentage is an utterly stupid idea, as there is no concrete definition of percentage representation in the audio loudness level.

Besides, alsa-lib never gives the value in percent.  It gives only raw values and the corresponding dB level.  It's applications who interpret it in a  percentage representation.

FWIW, in alsamixer (and amixer with an option), it's converted in a way with cubic root of the linear sample multiplication factor while the linear volume in small range (24dB).  Which is almost same as PulseAudio takes.

If you compare the value, you must check in either dB level or the raw value the hardware takes.

(In reply to Artem S. Tashkinov from comment #20)

> In short - what ALSA internally represents as e.g. 28% it exports as 50%
> volume.

I also noticed that PulseAudio allows the volume to be beyond 100%, so the maximum volume PA allows seems to be the 100% in Windows.

(In reply to Takashi Iwai from comment #21)
> Comparing in percentage is an utterly stupid idea, as there is no concrete
> definition of percentage representation in the audio loudness level.

On a technical level perhaps, that's the only thing that makes sense for human users.

> Which is almost same as PulseAudio takes.

Except PulseAudio allows for more than 100% volume.

(In reply to Felipe Contreras from comment #23)
> (In reply to Takashi Iwai from comment #21)
> > Comparing in percentage is an utterly stupid idea, as there is no concrete
> > definition of percentage representation in the audio loudness level.
> 
> On a technical level perhaps, that's the only thing that makes sense for
> human users.

We're dealing with a technical bug, not about human's feeling, aren't we?
Maybe my pessimism is 50% while yours is 28%; how to compare? :)

Again, the problem is to *compare* the sound level in percentage between different (operating) systems.  It's still useful to manage in percentage for a single volume in an application.  But this is not for comparing with something else, as it's no objective but just subjective matters.

Actually there are many different ways to represent a percent.  It could be simply a percent relative between raw min and raw max values (as amixer shows as default), it could be the converted dB level (as Windows does, IIRC), or it could be translated to more natural loudness (as alsamixer and amixer -M do), etc.  Without knowing the representation of the target percentage, you cannot compare at all.

> > Which is almost same as PulseAudio takes.
> 
> Except PulseAudio allows for more than 100% volume.

Irrelevant at all...

PA (and Windows, too) modifies the signal in software, thus it's not the hardware issue we're interested in for the kernel driver.
(And, with more than 100% volume, the signal is deformed due to the overload caps, resulting in a significant deterioration of audio quality.)

(In reply to Takashi Iwai from comment #24)
> 
> We're dealing with a technical bug, not about human's feeling, aren't we?
> Maybe my pessimism is 50% while yours is 28%; how to compare? :)
> 

The fact is that alsa-mixer shows a volume which is comparable to Windows, while what alsa-lib exports to all other applications is a very different value.

We can argue about the specifics of human perception ad infinitum, the simple fact is that naturally I'd like Windows and Linux to have the exact same volume given similar mixer settings. Why? Because Windows is an established platform so probably its developers had serious reasons to implement volume mixer the way it works right now. Most audio professions work in Windows ... you know.

I see no reason why Linux should be "unique" in this regard - it smells of noncompliance much more than speaks of any valid reasoning.

And let's avoid intertwining PulseAudio here - I don't have it installed.

P.S.

BTW, a trick to enable old idSoftware games to run on top of ALSA no longer works:

echo "quake3 0 0 direct" > /proc/asound/card0/pcm0p/oss

There's no oss file anywhere.

Do I understand correctly that this functionality was removed from the kernel and there's no way to mmap() Alsa's OSS implementation?

Don't tell me about various sound redirectors like aoss - none of them work.

(In reply to Artem S. Tashkinov from comment #25)
> (In reply to Takashi Iwai from comment #24)
> > 
> > We're dealing with a technical bug, not about human's feeling, aren't we?
> > Maybe my pessimism is 50% while yours is 28%; how to compare? :)
> > 
> 
> The fact is that alsa-mixer shows a volume which is comparable to Windows,

Which one?  alsamixer or amixer?  The latter shows the percentage relative to the raw values as default.  It's been unchanged to keep the compatibility with the old versions.

> while what alsa-lib exports to all other applications is a very different
> value.

Wrong.  As already mentioned, alsa-lib never exports any percentage value.  It gives only the hardware raw value and the corresponding dB value.
 
> We can argue about the specifics of human perception ad infinitum, the
> simple fact is that naturally I'd like Windows and Linux to have the exact
> same volume given similar mixer settings. Why? Because Windows is an
> established platform so probably its developers had serious reasons to
> implement volume mixer the way it works right now. Most audio professions
> work in Windows ... you know.

The audio professions never use percentage representation for comparing the sound level.
 
> I see no reason why Linux should be "unique" in this regard - it smells of
> noncompliance much more than speaks of any valid reasoning.

Again, it's application issue.  Not about alsa-lib, and not *at all* about the kernel.

(In reply to Artem S. Tashkinov from comment #26)
> And let's avoid intertwining PulseAudio here - I don't have it installed.
> 
> P.S.
> 
> BTW, a trick to enable old idSoftware games to run on top of ALSA no longer
> works:
> 
> echo "quake3 0 0 direct" > /proc/asound/card0/pcm0p/oss
> 
> There's no oss file anywhere.
> 
> Do I understand correctly that this functionality was removed from the
> kernel and there's no way to mmap() Alsa's OSS implementation?

Again an irrelevant issue.  The kernel support is there.  Nothing changed.
It's just the distro's setup whether to build or load the OSS compat module as default.

(In reply to Takashi Iwai from comment #28)
> 
> Again an irrelevant issue.  The kernel support is there.  Nothing changed.
> It's just the distro's setup whether to build or load the OSS compat module
> as default.

$ lsmod |awk '{print $1}'| grep oss
snd_seq_oss
snd_pcm_oss
snd_mixer_oss

$ ls -R /proc/asound/
/proc/asound/:
card0  card1  card2  cards  devices  hwdep  IntelHDA  LogitechUSB  modules  NVidia  oss  pcm  seq  timers  version

/proc/asound/card0:
codec#0  id  oss_mixer

/proc/asound/card1:
codec#0  eld#0.0  eld#0.1  eld#0.2  eld#0.3  id  oss_mixer

/proc/asound/card2:
id  oss_mixer  stream0  usbbus  usbid  usbmixer

/proc/asound/oss:
devices  sndstat

/proc/asound/seq:
clients  drivers  oss  queues  timer

No OSS file under any sound card.

(In reply to Takashi Iwai from comment #27)
> (In reply to Artem S. Tashkinov from comment #25)
> > (In reply to Takashi Iwai from comment #24)
> > > 
> > > We're dealing with a technical bug, not about human's feeling, aren't we?
> > > Maybe my pessimism is 50% while yours is 28%; how to compare? :)
> > > 
> > 
> > The fact is that alsa-mixer shows a volume which is comparable to Windows,
> 
> Which one?  alsamixer or amixer?  The latter shows the percentage relative
> to the raw values as default.  It's been unchanged to keep the compatibility
> with the old versions.

$ rpm -qf `which alsamixer`
alsa-utils-1.0.22-5.el6.i686

> 
> > while what alsa-lib exports to all other applications is a very different
> > value.
> 
> Wrong.  As already mentioned, alsa-lib never exports any percentage value. 
> It gives only the hardware raw value and the corresponding dB value.

You can change that.

>  
> > We can argue about the specifics of human perception ad infinitum, the
> > simple fact is that naturally I'd like Windows and Linux to have the exact
> > same volume given similar mixer settings. Why? Because Windows is an
> > established platform so probably its developers had serious reasons to
> > implement volume mixer the way it works right now. Most audio professions
> > work in Windows ... you know.
> 
> The audio professions never use percentage representation for comparing the
> sound level.

Sounds like Windows also uses dB based mixer.

>  
> > I see no reason why Linux should be "unique" in this regard - it smells of
> > noncompliance much more than speaks of any valid reasoning.
> 
> Again, it's application issue.  Not about alsa-lib, and not *at all* about
> the kernel.

Yes, I was talking about alsa-lib, not about the kernel. You can make relevant alsa-lib changes so that audio mixer worked in a manner which is compliant with the most popular, read de-facto, desktop OS.

I do understand you are against making such changes, so if you could provide a patch for that (without actually merging it anywhere), I'd be very grateful. I'm not really a programmer to dig and makes changes in the alsa-lib sources.

(In reply to Artem S. Tashkinov from comment #30)
> (In reply to Takashi Iwai from comment #27)
> > (In reply to Artem S. Tashkinov from comment #25)
> > > (In reply to Takashi Iwai from comment #24)
> > > > 
> > > > We're dealing with a technical bug, not about human's feeling, aren't
> we?
> > > > Maybe my pessimism is 50% while yours is 28%; how to compare? :)
> > > > 
> > > 
> > > The fact is that alsa-mixer shows a volume which is comparable to
> Windows,
> > 
> > Which one?  alsamixer or amixer?  The latter shows the percentage relative
> > to the raw values as default.  It's been unchanged to keep the
> compatibility
> > with the old versions.
> 
> $ rpm -qf `which alsamixer`
> alsa-utils-1.0.22-5.el6.i686
> 
> > 
> > > while what alsa-lib exports to all other applications is a very different
> > > value.
> > 
> > Wrong.  As already mentioned, alsa-lib never exports any percentage value. 
> > It gives only the hardware raw value and the corresponding dB value.
> 
> You can change that.
 
Why?  You don't understand what you're requesting...

> > > We can argue about the specifics of human perception ad infinitum, the
> > > simple fact is that naturally I'd like Windows and Linux to have the
> exact
> > > same volume given similar mixer settings. Why? Because Windows is an
> > > established platform so probably its developers had serious reasons to
> > > implement volume mixer the way it works right now. Most audio professions
> > > work in Windows ... you know.
> > 
> > The audio professions never use percentage representation for comparing the
> > sound level.
> 
> Sounds like Windows also uses dB based mixer.

There is a big difference between dB and percentage.  A dB level can't be converted to percentage linearly.  If you do it, there are some implicit assumptions.  Thus, to repeat myself again: the percentage isn't suitable at all for comparing the sound level in different systems.

> > > I see no reason why Linux should be "unique" in this regard - it smells
> of
> > > noncompliance much more than speaks of any valid reasoning.
> > 
> > Again, it's application issue.  Not about alsa-lib, and not *at all* about
> > the kernel.
> 
> Yes, I was talking about alsa-lib, not about the kernel. You can make
> relevant alsa-lib changes so that audio mixer worked in a manner which is
> compliant with the most popular, read de-facto, desktop OS.

Again, alsa-lib has *NOTHING* to do with the percentage representation.
Never.  Nada.  I already wrote multiple times in this bugzilla.
 
That is, this is merely an issue of application, not the system library nor kernel driver.

So, I close this bug as INVALID for the reason above.

Feel free to reopen if you get the reasonable comparison using the objectively measurable unit.

(In reply to Artem S. Tashkinov from comment #29)
> (In reply to Takashi Iwai from comment #28)
> > 
> > Again an irrelevant issue.  The kernel support is there.  Nothing changed.
> > It's just the distro's setup whether to build or load the OSS compat module
> > as default.
> 
> $ lsmod |awk '{print $1}'| grep oss
> snd_seq_oss
> snd_pcm_oss
> snd_mixer_oss
> 
> $ ls -R /proc/asound/
> /proc/asound/:
> card0  card1  card2  cards  devices  hwdep  IntelHDA  LogitechUSB  modules 
> NVidia  oss  pcm  seq  timers  version
> 
> /proc/asound/card0:
> codec#0  id  oss_mixer
> 
> /proc/asound/card1:
> codec#0  eld#0.0  eld#0.1  eld#0.2  eld#0.3  id  oss_mixer
> 
> /proc/asound/card2:
> id  oss_mixer  stream0  usbbus  usbid  usbmixer
> 
> /proc/asound/oss:
> devices  sndstat
> 
> /proc/asound/seq:
> clients  drivers  oss  queues  timer
> 
> No OSS file under any sound card.

Did you build with CONFIG_SND_VERBOSE_PROCFS?  The proc file won't appear without that kconfig.  It works fine on my system, the oss proc file appears there.

If the problem still happens with the kconfig, open another bug report, instead of hanging on an irrelevant bug report.

(In reply to Artem S. Tashkinov from comment #26)
> And let's avoid intertwining PulseAudio here - I don't have it installed.
> 

you still not remove pulseaudio completely

!!ALSA configuration files
!!------------------------

!!System wide config file (/etc/asound.conf)

#
# Place your global alsa-lib configuration here...
#

@hooks [
	{
		func load
		files [
			"/etc/alsa/pulse-default.conf"
		]
		errors false
	}

(In reply to Raymond from comment #33)
> (In reply to Artem S. Tashkinov from comment #26)
> > And let's avoid intertwining PulseAudio here - I don't have it installed.
> > 
> 
> you still not remove pulseaudio completely
> 
> !!ALSA configuration files
> !!------------------------
> 
> !!System wide config file (/etc/asound.conf)
> 
> #
> # Place your global alsa-lib configuration here...
> #
> 
> @hooks [
>       {
>               func load
>               files [
>                       "/etc/alsa/pulse-default.conf"
>               ]
>               errors false
>       }

/etc/alsa/pulse-default.conf is not here. It's empty.

(In reply to Takashi Iwai from comment #32)
> 
> Did you build with CONFIG_SND_VERBOSE_PROCFS?  The proc file won't appear
> without that kconfig.  It works fine on my system, the oss proc file appears
> there.
> 
> If the problem still happens with the kconfig, open another bug report,
> instead of hanging on an irrelevant bug report.

config SND_VERBOSE_PROCFS
        bool "Verbose procfs contents"
        depends on PROC_FS
        default y
        help
          Say Y here to include code for verbose procfs contents (provides
          useful information to developers when a problem occurs).  On the
          other side, it makes the ALSA subsystem larger.

The documentation on this option is clearly lacking. Please, add the fact that this option is required for OSS configuration as well.

It's kinda awful that in order to fix something in Linux sometimes I have to argue with kernel developers. It's not normal for an OS striving to be a Windows replacement on the desktop.

(In reply to Takashi Iwai from comment #31)
>  
> That is, this is merely an issue of application, not the system library nor
> kernel driver.
> 
> So, I close this bug as INVALID for the reason above.
> 
> Feel free to reopen if you get the reasonable comparison using the
> objectively measurable unit.

What about a patch that will make all mixers other than CLI alsamixer (which already works like I want it) behave in a manner which is consistent with this very utility and Windows? I know it's possible, I know it's super easy for you.

Again I'm _not_ asking to _merge_ it, just to have it here will be enough for those of use who seek consistency and compatibility with Windows. I.e. I don't want to break my head every time I reboot from Windows to Linux and vice versa.

Can we please stop arguing about the merits of volume representation? All I'm asking is to make GUI mixers in Linux behave in a manner which is comparable to alsamixer and Windows. No, I have no desire to ask several dozen different OSS developers to patch their GUI mixers - it's beyond insane - it will take ages to be implemented and it will introduce the incompatibility in volume representation between different mixers. Besides they will probably not be interested in patching what's already working fine.

(In reply to Artem S. Tashkinov from comment #36)
> (In reply to Takashi Iwai from comment #31)
> >  
> > That is, this is merely an issue of application, not the system library nor
> > kernel driver.
> > 
> > So, I close this bug as INVALID for the reason above.
> > 
> > Feel free to reopen if you get the reasonable comparison using the
> > objectively measurable unit.
> 
> What about a patch that will make all mixers other than CLI alsamixer (which
> already works like I want it) behave in a manner which is consistent with
> this very utility and Windows? I know it's possible, I know it's super easy
> for you.

Stop dreaming.  This isn't possible.  Simply because the percentage representation isn't provided in the API level.  Only the raw value and the dB level are provided, as repeatedly mentioned.  How can you patch to what you don't provide?

I'm not dreaming.

Let's reason.

As far as I can see alsa-lib (in case of Intel HDA) exports the master volume range as:

0dB .. 64dB (or -64dB .. 0dB)

For alsamixer and probably Windows (I cannot compare their values, but they seem to be similar) 50% volume means 48dB (or -16dB - I cannot quite figure it out), i.e. something which resembles a logarithmic scale.

I see no reason not to exports values which are decimal in nature but translate to the same logarithmic scale which CLI alsamixer uses internally.

Isn't it easily doable? BTW, this can be changed in the Intel HDA driver itself or introduced as a module option, something like logarithmic_volume=1.

And one last question: why does Windows use a logarithmic scale for the master channel volume (I'm not sure about others)? And what prevents us from following Windows, read currently accepted standard? Besides Intel/Realtek developed their SoC primarily as a Windows solution, which later became supported by MacOS and Linux so the way Windows handles volume seems to be something well thought.

Grrr, I have to repeat my self: here is bugzilla.kernel.org.  It's no user forum.  It's a place to track and fix *KERNEL* bugs.  The topic you're dealing with is completely irrelevant from the kernel stuff.  So, Artem, if you want to continue discussion on it, please do it on ML.

A few more notes, though:

- The HD-audio raw value is already logarithmic, thus the (so to say) wrongly behaving mixer apps already handle values in logarithmic way.  This isn't the problem.

- The human neutral mapping cannot be either logarithmic nor linear.  It's between them.  (It's quite obvious if you think of the value zero.)  Here comes the difficulty.

- Windows doesn't handle the hardware chip volume.  It's using 0dB, and the rest is done in software by modifying signals.  This is of course bad from the sound quality and CPU usage POV, while it simplifies the volume handling.  (BTW, This is one of the biggest reasons why professional audio apps don't use the Windows API, but other infrastructure like ASIO.)

- I'm not against adding some new API functions to alsa-lib; it'd be good.  But you'd still need to fix every mixer app to adapt the new stuff.  That's why I wrote there is no magical patch, and it's rather an application issue.

- This is my last comment on the bug.  I won't write any more.  If you'd like to discuss, do it on ML.

(In reply to Takashi Iwai from comment #24)
> (In reply to Felipe Contreras from comment #23)
> > (In reply to Takashi Iwai from comment #21)
> > > Comparing in percentage is an utterly stupid idea, as there is no
> concrete
> > > definition of percentage representation in the audio loudness level.
> > 
> > On a technical level perhaps, that's the only thing that makes sense for
> > human users.
> 
> We're dealing with a technical bug, not about human's feeling, aren't we?
> Maybe my pessimism is 50% while yours is 28%; how to compare? :)

This is irrelevant. Ultimately if the technical solution that gives the user a percentage gives it wrong, the technical solution is wrong.

The problem remains the same; the *maximum* volume (regardless of how you want to represent it) is much lower in Linux than in Windows.

> > > Which is almost same as PulseAudio takes.
> > 
> > Except PulseAudio allows for more than 100% volume.
> 
> Irrelevant at all...
> 
> PA (and Windows, too) modifies the signal in software, thus it's not the
> hardware issue we're interested in for the kernel driver.

I always thought I didn't need PulseAudio, but I can't hear shit with ALSA, maybe I do need PulseAudio after all, just so I can hear the audio I want.

> (And, with more than 100% volume, the signal is deformed due to the overload
> caps, resulting in a significant deterioration of audio quality.)

That's not true. That happens *only* if the audio signal is already loud to begin with, if it's low volume it won't get distorted. Even if it was deformed, at least I can hear it.

Mark it as invalid if you want, but the problem is still there. A shame that you don't want to fix it.

Felipe, you also completely misunderstood the argument.  The bug is closed as it's insisted in the stupid percentage representation issues.  It's no kernel problem at all, thus no reason to track here.  The too low max volume is a different story.  So I'll continue checking on bug 62651.  (But you never replied there.)

(In reply to Takashi Iwai from comment #41)
> Felipe, you also completely misunderstood the argument.  The bug is closed
> as it's insisted in the stupid percentage representation issues.

That is off-topic, once again, the *maximum* volume (regardless of how you want to represent it) is much lower in Linux than in Windows. That is a valid problem.

The fact that Artem can't concentrate on a single topic doesn't make the problem invalid.

> It's no kernel problem at all

That is an assumption. Quite likely, but still an assumption. There might still be something in the kernel that isn't realizing the maximum volume.

> The too low max volume is a different story.

I see it as the same.

> So I'll continue checking on bug 62651.  (But you never replied there.)

Well, I don't see it as a separate bug, but given the fact that using PulseAudio the problem goes away, I assumed the problem was identified.

No, to verify that there's no issue on the kernel side, the only way I can think of is to somehow disable software amplification in Windows, and to query the hardware volume. Alas, I don't know how to do that.

Finally although slightly off-topic it would be nice to know if there's a way to tell ALSA to turn on software amplification.