Page 7 of 17 FirstFirst ... 56789 ... LastLast
Results 61 to 70 of 161

Thread: Systemd 199 Has Its Own D-Bus Client Library

  1. #61
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,666

    Default

    Quote Originally Posted by frign View Post
    And? I never stated to evaluate it; I pointed out configuration and code was separated.
    And that's also how it works in systemd.

    Quote Originally Posted by Ericg View Post
    I just pulled up htop and checked pulse's CPU usage while playing music-- sorted by CPU%, pulse was at the bottom of the list alongside packagekit (idle) and samba (no connections sending or receiving). If pulse is spiking your CPU or someone elses CPU its from buggy drivers or bad configurations (very possible. Check the arch wiki, pulse's defaults dont work on all cards. Sometimes they need adjusting)
    Huh, I never really tried this, but you're right. I get 1% CPU usage by Amarok, and PulseAudio itself is constantly at 0%. Pretty cool, I didn't quite expect that. And that's while running with ctxfi drivers, which are far from optimal, while using default settings...

  2. #62
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Default

    Quote Originally Posted by Teho View Post
    The OpenRC people seem to think that Wikipedia is their marketing platform. It doesn't have sources either and there's even a "This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. See Wikipedia's guide to writing better articles for suggestions. (December 2012)" banner on top of the page. All in all that part of the article should probably be removed as off-topic, unreferenced and biased trash.

    Could you point me where the kernel part of Jack is? ...and how exactly does it make Jack better than PulseAudio.

    Neither of the articles I linked were authored by Lennart.
    Ok, agreed. I forgot to note that, because I am also a Wikipedia-sceptic and will investigate myself now in regards to SLsOC. In which way OpenRC use it as a marketing-platform is questionable.

    Jack is in Kernel, because there are extensions to the ALSA-implementation for Jack support (especially in regards to timers, esp. HRTs)

    Ok, my mistake in regards to the articles. I misread one earlier post and I thought it was actually part of Lennart's blog, not actually checking it.

  3. #63
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Default

    Quote Originally Posted by GreatEmerald View Post
    And that's also how it works in systemd.



    Huh, I never really tried this, but you're right. I get 1% CPU usage by Amarok, and PulseAudio itself is constantly at 0%. Pretty cool, I didn't quite expect that. And that's while running with ctxfi drivers, which are far from optimal, while using default settings...
    If a sound daemon was using more than 1% in regards to today's advanced hardware, I would be definitely concerned. How about RAM?

  4. #64
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,938

    Default

    Quote Originally Posted by frign View Post
    If a sound daemon was using more than 1% in regards to today's advanced hardware, I would be definitely concerned. How about RAM?
    0.0%

    VIRT: 539M
    RES: 1844
    SHR: 1522

    (As reported by htop)

  5. #65
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote Originally Posted by frign View Post
    In which way OpenRC use it as a marketing-platform is questionable.
    Well it used to have a comparison table like this... on top of the SLOC comparisons.

    Quote Originally Posted by frign View Post
    Jack is in Kernel, because there are extensions to the ALSA-implementation for Jack support (especially in regards to timers, esp. HRTs)
    Doesn't PulseAudio use exactly the same timers stuff as Jack? At least PulseAudio is build around timers and some if not most of the early problems relating to PulseAudio existed because the ALSA drivers reported wrong timing information.

  6. #66
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    241

    Default

    About the sound thing, why don't turn back oss?

  7. #67
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,938

    Default

    Quote Originally Posted by Thaodan View Post
    About the sound thing, why don't turn back oss?
    Lack of development, buggy drivers, very limited features (I know for a fact no jack detection), and in-kernel nature meant that its buggy drivers could bring down the whole kernel.

    EDIT: From the Arch wiki (https://wiki.archlinux.org/index.php/Open_Sound_System)

    Comparisons with ALSA

    Some advantages and disadvantages compared to using the Advanced Linux Sound Architecture.
    OSS Advantages (users)
    Per-application volume control.
    Lower latency due to everything running within the Linux Kernel. Initial response time in audio applications is usually better.
    OSS always has sound mixing, ALSA does not.
    Sound mixing is of higher quality, due to OSS using more precise math in its sound mixing.
    Some legacy cards have better support.

    OSS Advantages (developers)
    Support for drivers in userspace.
    Cross-platform (OSS runs on BSDs and Solaris).
    Cleaner and easier to use API.

    ALSA advantages over OSS
    Better support for USB audio devices.
    Support for Bluetooth audio devices.
    Support for AC'97 and HD Audio dial-up soft-modems such as Si3055.
    Better support for MIDI devices.
    Support for suspend.
    Better support for jack detection.
    Note:
    OSS has experimental output support for USB audio devices, but no input.
    Last I checked, OSS actually has NO support for suspend. If you want to suspend you have to unload OSS, suspend, then reload it on wake.
    Last edited by Ericg; 03-27-2013 at 08:12 PM.

  8. #68
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote Originally Posted by Thaodan View Post
    About the sound thing, why don't turn back oss?
    Why would anyone want that? It's severly outdated architecture, solves no problems and adds quite a few and Linux already has a excellent audio infrastucture that supports incredible ammount of hardware (over 4000 chips or something). I doubt anyone is interested in reimplementing that. ALSA is also very widely used (Android, Chrome OS, desktop Linux...).

    There was an interesting debate between dawhead (Paul Davis, the lead developer of Ardour and Jack) and Hannu Savolainen (the lead developer of OSSv4) here in the comments if you are interested in reading.
    Last edited by Teho; 03-27-2013 at 08:13 PM.

  9. #69
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Cool

    Quote Originally Posted by Ericg View Post
    0.0%

    VIRT: 539M
    RES: 1844
    SHR: 1522

    (As reported by htop)
    Nice values, even though, ofc, this depends on how much it is idling.
    Memory could be better, though.

  10. #70
    Join Date
    Jan 2009
    Posts
    1,496

    Default

    Quote Originally Posted by duby229 View Post
    The only thing that PA does that is kinda nice is its per application volume control. Thats it. But its soooo huge that it simply isnt worth it to get that slight advantage. It's performance is so bad that even the slightest cpu load makes it skip and crackle. Simply put, it's some of the worst software ever written for little to no gain with lots and lots to lose.

    Alsa running by itself on the other hand will easily fit the needs of almost everyone.

    Yeah, well, you know, that's just, like, your opinion, man.
    Right now I'm listening to some music while running two instances of dd as root which is pegging the cores. Music plays back perfectly. BTW, I running this on T7500 cores, not that that should matter.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •