Simplified and uniform volume handling - asking for opinions
Hi Recently, the sound scaling patch was committed to CVS. Since I think that this patch over-complicates things, I want to suggest an alternative solution which I think is better. I prepared a patch that changes the following things: - Removed the various sound scaling options again - Volume setting in dB on all targets, with the 'natural' range defined by the respective DAC -78..+18 dB for archos Player -115..+12 dB for archos Recorders and Ondios -84.. 0 dB for iriver H1x0 and H3x0 - No artificial volume limiting. On the targets which need this handling (archos Player, iriver), the prescaler is used at lower volumes to avoid clipping like before, but at high volumes, prescaling is reduced again. Patch #1374123 on SourceForge: http://sourceforge.net/tracker/index.php?func=detailaid=1374123group_id=44306atid=439120 This has the following advantages: - Less option clutter with less confusion - More KISS and more uniform code across targets - 0 dB volume mean line level on all platforms - Sound settings always represent the actual values. It was less-than-optimal before when the volume was modified in the background, but the sound scaling patch extended this behind-the-scenes mangling to treble and bass, even in a possibly unpredictable way when 'adjust current' is selected. The sound scaling patch had one good effect: it forced me to think about the volume scaling, and perform some experiments which finally convinced me that not capping the volume is better. - We don't cap the volume on archos Recorders and Ondios for years - Archos recorders and Ondios may even clip at the (equivalent of) 0 dB (92 %) with high treble/bass boost plus high loudness setting - Maximum possible volume on iriver is lower than on all archos targets - Future addition of EQ (iriver) / replaygain (archos) would complicate things even more, and force us to reduce maximum volume further if we want to continue to guarantee no clipping. Now I am asking for opinions/ suggestions on this. I would really like to commit this... Regards, Jens
Re: Simplified and uniform volume handling - asking for opinions
Jens Arnold wrote: Now I am asking for opinions/ suggestions on this. I would really like to commit this... Gets my vote. Linus
Re: Simplified and uniform volume handling - asking for opinions
Jens Arnold wrote: Now I am asking for opinions/ suggestions on this. I would really like to commit this... This is more or less exactly what I've wanted all along, so thumbs up from me. Thom
RE: Simplified and uniform volume handling - asking for opinions
On Tue, 6 Dec 2005, Anton Oleynikov wrote: The whole point of me doing first patch was that second option. It was extensively discussed in the forum and now that seem to be eliminated, right? In the forum perhaps, but not a lot here. How come? Jens explained it pretty well in his mail, IMHO. And no matter what, it is always considered fine to improve whatever we did before. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: Simplified and uniform volume handling - asking for opinions
On Tue, 6 Dec 2005, Anton Oleynikov wrote: And no matter what, it is always considered fine to improve whatever we did before. Improve - yes, but completely remove what I've just done after not even speak up when asked - its another thing :) But he mailed here now and we're debating it atm. He hasn't committed anything yet. Feel free to argue for your viewpoint. There's no point in debating why the debate was lacking or made differently before. AFAICS, we're pretty united supporting his approach. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Simplified and uniform volume handling - asking for opinions
Anton Oleynikov wrote: The whole point of my patch was that user finally have intelligent bass/volume control that allow him to compare sound directly to original iRiver's firmware This is absolutely irrelevant IMHO. We couldn't care less about the original firmware. Linus
Re: Simplified and uniform volume handling - asking for opinions
On Tue, 6 Dec 2005, Michael E. DiFebbo wrote: I also believe that having a prevent clipping function similar to what Anton developed is beneficial to Rockbox, particularly with respect to making it more accessible to less sophisticated users. All the discussions that have been held on this topic, that I've read, have more or less stated that people have not understood or liked the previous concept used by Rockbox, with some stating that they'd prefer the original iriver fw method. The approach Jens suggested has not been widely discussed or tested. we also retain at least the portion of Anton's prevent clipping function that scales back bass boost to prevent clipping. Yes, we might have to. But we've had Jens' system for the Archos models for years without needing a prevent clipping option so I think it is a fair idea to go without that option to start with. People are in fact used to stereo equipments etc that clip when you drive everything to too high levels. Also, it is not 100% clear exactly how the scale back bass should work. Many of you have argued, in various ways, that Anton's approach is less desirable then Jens' approach because Anton's approach leads to undesirable option bloat. That's only one reason. There are more reasons, including: there are too much magic happenining under the hood and that the options are very hard to understand/differentiate. The premise underlying these arguments is that Rockbox already has too many options and that adding more makes it unapproachable to new users or overly complex.* I disagree with this premise for several reasons. The ground rule, that many of us core devs are sticking to, is that adding options is a necessary evil that you avoid as far as possible. In a few years from now, you too will realize why this is a winning concept. First, I think that this issue goes directly to the heart of what an audio jukebox is about: the users' experience in listening to music. It is abundantly clear that the handing of volume and clipping is important to the Rockbox user base. I disagree. It is not clear. It is clear that the previous approach surprised a lot of previous iriver-firmware users. It's also clear that this issue is critical to the developers; Yes, but to me at least more in the sense that we want to keep Rockbox simple, understandable and without bloat. I've never personally experienced the cap limit, be it the original or Rockbox's, not before not now. I don't understand why there is such reluctance to implement a configurable option with respect to clipping prevention. Because if we can work out a system without an added option, that is an even better approach. There are many other Rockbox functions that have more numerous and more complex options. That is not a good argument. Just because we have been sloppy or done mistakes in the past is not a good reason for us to do them again. The peak meter alone, for example, has SIX different options. The LCD has NINE different options. The crossfade function has six different options I would say that each of these are example of option-bloats that we should address and cut down on. But it isn't easy to remove or cut down what has already gone into Rockbox as there's a wild user base that likes every part you'd try to change. It is _a lot_ easier to break and address things _before_ they go in in the first place. And in fact, if we had not been practising the More Options Are Evil philosophy we'd have a *bazillion* more options than we have today. It doesn't seem unreasonable for users to have at least ONE option (ON or OFF) with respect to clipping prevention. ... nope, and there is no major resistance against such an option. Just a mild Do we really need it? And a How exactly would such an option work? And a Such an option *really* should be user-visible when in effect and how would that work when the apps don't have detailed info about the DAC? etc If there really is a belief that Rockbox has too many options I think most people (both devs and users) would say so. Advanced settings I'm against advanced or expert options. We've had this argument many times and I firmly believe: 1) we'd get lots of arguements which options that are advanced 2) all users would still use the advanced options I do NOT think that bass limiting should be implemented because that is the way that iriver does it. I agree. Rockbox is a lot more than an iriver firmware and we do not mimic iriver's behaviour. We should do what we consider is The Right Thing in any given situation. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
missing remote-settings-patch
Hi, i have create a patch which adds some currently missing settings for the remote-lcd. So i want to hear if someone have some suggestions/objection about this patch :) http://sourceforge.net/tracker/index.php?func=detailaid=1362248group_id=44306atid=439120 Stephan
Re: new wps-file-loader
On Tue, 6 Dec 2005, Stephan Wezel wrote: The loading of a wps-file is done line-by-line. Does it still require some special formatting (on their own line or similar) of certain tags? I seem to recall that it at leased used to do that, or I am just staying up too late now again? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: another unicode bitmap font...
Information about this font and samples, are located at: http://crl.nmsu.edu/~mleisher/cu.html Frederic, could you provide a page with some samples for us to see? The link in the README points to an 'under construction' page. Thanks, -id
Re: new wps-file-loader
yes but only for the %we and %wd tags currently they can stay everywhere exept in comment-lines and %x and %xl lines. with this loader these two tags (%we, %wd) must be on a seperate line. But this will not introduce a new-line in the displayed wps because the complete line gets ignored. Stephan
