Re: [openstack-dev] [Ironic][Neutron] Ironic/Neutron Integration weekly meeting kick off
Sukhdev, Thank you for your settings! Looking forward to meeting you next week. -- pshige 2015-05-28 13:59 GMT+09:00 Sukhdev Kapur sukhdevka...@gmail.com: Folks, Starting next monday (June 1, 2015), we are kicking off weekly meeting to discuss and track the integration of Ironic and Neutron (ML2). We are hoping to implement the Networking support within Liberty cycle. Come join and help us achieve this goal. Anybody who is interested in this topic, wants to contribute, share their wisdom with the team, are welcome to join us. Here are the details of the meeting: Weekly on Mondays at 1600 UTC (9am Pacific Time) IRC Channel - #openstack-meeting-4 Meeting Agenda and team charter - https://wiki.openstack.org/wiki/Meetings/Ironic-neutron Feel free to add a topic to the agenda for discussion. Looking forward to meeting you in the channel. regards.. -Sukhdev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison
My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. Thanks for all your work and service. -- pshige 2015-05-26 1:45 GMT+09:00 Ghe Rivero g...@debian.org: My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1440538] Re: Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py
** No longer affects: openstack-manuals ** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: openstack-manuals Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1440538 Title: Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py Status in OpenStack Bare Metal Provisioning Service (Ironic): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Magnum - Containers for OpenStack: Fix Released Status in OpenStack Manuals: New Status in Messaging API for OpenStack: Fix Released Bug description: verifing - verifying. This typo affects a lot of projects, too. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1440538/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1443464] [NEW] glance/doc/source/architecture.rst has non-ascii characters”
Public bug reported: Basic architecture section has non-ascii (utf-8) characters. ** Affects: glance Importance: Undecided Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: New ** Changed in: glance Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1443464 Title: glance/doc/source/architecture.rst has non-ascii characters” Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Basic architecture section has non-ascii (utf-8) characters. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1443464/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440538] [NEW] Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py
Public bug reported: verifing - verifying. This typo affects a lot of projects, too. ** Affects: ironic Importance: Low Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: In Progress ** Affects: keystone Importance: Undecided Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: In Progress ** Affects: openstack-manuals Importance: Undecided Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: In Progress ** Affects: oslo.messaging Importance: Undecided Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: In Progress ** Affects: sahara Importance: Undecided Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: In Progress ** Also affects: ironic Importance: Undecided Status: New ** Changed in: ironic Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) ** Changed in: oslo.messaging Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) ** Also affects: sahara Importance: Undecided Status: New ** Changed in: sahara Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) ** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) ** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: openstack-manuals Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1440538 Title: Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py Status in OpenStack Bare Metal Provisioning Service (Ironic): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Manuals: In Progress Status in Messaging API for OpenStack: In Progress Status in OpenStack Data Processing (Sahara): In Progress Bug description: verifing - verifying. This typo affects a lot of projects, too. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1440538/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440538] Re: Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py
Vitaly, thank you for your comment. I removed sahara from affected projects. ** No longer affects: sahara -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1440538 Title: Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py Status in OpenStack Bare Metal Provisioning Service (Ironic): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Magnum - Containers for OpenStack: In Progress Status in OpenStack Manuals: In Progress Status in Messaging API for OpenStack: In Progress Bug description: verifing - verifying. This typo affects a lot of projects, too. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1440538/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440538] Re: Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py
a typo in oslo.messaging/oslo_messaging/_drivers/protocols/amqp/opts.py: help=CA certificate PEM file for verifing server certificate), affects /sahara/etc/sahara/sahara.conf.sample:# CA certificate PEM file for verifing server certificate (string and so on. ** Also affects: magnum Importance: Undecided Status: New ** Changed in: magnum Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) ** Changed in: magnum Status: New = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1440538 Title: Fix typo in oslo_messaging/_drivers/protocols/amqp/opts.py Status in OpenStack Bare Metal Provisioning Service (Ironic): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Magnum - Containers for OpenStack: In Progress Status in OpenStack Manuals: In Progress Status in Messaging API for OpenStack: In Progress Bug description: verifing - verifying. This typo affects a lot of projects, too. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1440538/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
Re: [openstack-dev] [kolla] Announcing k3 release of Kolla
sdake, cool! -- pshige 2015/03/25 0:29 Steven Dake (stdake) std...@cisco.com: Hello, The Kolla community is pleased to announce the release of Kilo #3 of the Kolla project. It is available for immediate download from: https://github.com/stackforge/kolla/archive/k3.tar.gz This version removes Kubernetes entirely as a development environment. We found we needed super-privileged containers to properly deploy OpenStack. As a result we are now using docker-compose. The heat-community is in the process of producing a resource for managing oocker-compose components. This should permit the integration of Kolla with third party tools that use Heat for deployment. Alternatively docker-compose can be used directly. To get started, read the quickstart guide: https://github.com/stackforge/kolla/blob/master/docs/developer-env.md This version allows the starting of a full container on bare-metal deployment. The tools/start script will deploy a working deployment of: - mariadb - rabbitmq - keystone - glance-api and glance-registry - nova-api, nova-conductor, and nova-scheduler - libvirt, nova-compute, nova-network - heat-api and heat-engine - Horizon This version of Kolla uses OpenStack Legacy networking called nova-network. Make sure to edit the /tools/genev and supply the correct device name (i.e. eth1) for the interface used by nova-network's FLAT_INTERFACE. For more on Nova networking, please refer to: http://docs.openstack.org/juno/install-guide/install/yum/content/section_nova-networking.html New Features - A new implementation based upon super-privileged containers - Docker-compose has replaced kubernetes as the deployment tool - Documentation for starting a development environment - Documentation for integrating with Kolla - Improved parameterization of OpenStack configuation files. Quickstart: - Run tools/genenv.sh to generate your environment variables - Source your credentials (openrc), which will be added kolla/ directory - Install the openstack clients on your host - Test out individual services: - $ keystone user-list Please give it a run today and provide your feeedback! Regards, - The Kolla Core Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] ironic-discoverd release plans
Dmitry, Thank you! Great! pshige 2015-03-21 0:18 GMT+09:00 高田唯子 yuikotakada0...@gmail.com: Thank you, Dmitry. I agree! Best Regards, Yuiko Takada 2015-03-20 23:32 GMT+09:00 Imre Farkas ifar...@redhat.com: Hi Dmitry, Sounds good to me! ;-) Imre On 03/20/2015 01:59 PM, Dmitry Tantsur wrote: This is an informational email about upcoming ironic-discoverd-1.1.0 [1]. If you're not interested in discoverd, you may safely skip it. Hi all! Do you know what time is coming? Release time! I'm hoping to align this ironic-discoverd release with the OpenStack one. Here's proposed plan, which will be in effect, unless someone disagrees: Apr 9: feature freeze. The goal is to leave me some time to test it with Ironic RC and in-progress devstack integration [2]. Between this point and the release day, git master can be considered a release candidate :) Apr 30: release and celebration. stable/1.1 is branched and master is opened for features. For better scoping I've untargeted everything from 1.1.0 milestone [1], except for thing I see as particularly important. We might add more if we have time before FF. Please let me know what you think. Cheers, Dmitry [1] https://launchpad.net/ironic-discoverd/+milestone/1.1.0 [2] https://etherpad.openstack.org/p/DiscoverdDevStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Kolla] PTL Candidacy
Congrats, sdake !! -- pshige 2015-03-18 16:09 GMT+09:00 Daniel Comnea comnea.d...@gmail.com: Congrats Steve! On Wed, Mar 18, 2015 at 12:51 AM, Daneyon Hansen (danehans) daneh...@cisco.com wrote: Congratulations Steve! Regards, Daneyon Hansen Software Engineer Email: daneh...@cisco.com Phone: 303-718-0400 http://about.me/daneyon_hansen From: Angus Salkeld asalk...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, March 17, 2015 at 5:05 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Kolla] PTL Candidacy There have been no other candidates within the allowed time, so congratulations Steve on being the new Kolla PTL. Regards Angus Salkeld On Thu, Mar 12, 2015 at 8:13 PM, Angus Salkeld asalk...@mirantis.com wrote: Candidacy confirmed. -Angus On Thu, Mar 12, 2015 at 6:54 PM, Steven Dake (stdake) std...@cisco.com wrote: I am running for PTL for the Kolla project. I have been executing in an unofficial PTL capacity for the project for the Kilo cycle, but I feel it is important for our community to have an elected PTL and have asked Angus Salkeld, who has no outcome in the election, to officiate the election [1]. For the Kilo cycle our community went from zero LOC to a fully working implementation of most of the services based upon Kubernetes as the backend. Recently I led the effort to remove Kubernetes as a backend and provide container contents, building, and management on bare metal using docker-compose which is nearly finished. At the conclusion of Kilo, it should be possible from one shell script to start an AIO full deployment of all of the current OpenStack git-namespaced services using containers built from RPM packaging. For Liberty, I’d like to take our community and code to the next level. Since our containers are fairly solid, I’d like to integrate with existing projects such as TripleO, os-ansible-deployment, or Fuel. Alternatively the community has shown some interest in creating a multi-node HA-ified installation toolchain. I am deeply committed to leading the community where the core developers want the project to go, wherever that may be. I am strongly in favor of adding HA features to our container architecture. I would like to add .deb package support and from-source support to our docker container build system. I would like to implement a reference architecture where our containers can be used as a building block for deploying a reference platform of 3 controller nodes, ~100 compute nodes, and ~10 storage nodes. I am open to expanding our scope to address full deployment, but would prefer to merge our work with one or more existing upstreams such as TripelO, os-ansible-deployment, and Fuel. Finally I want to finish the job on functional testing, so all of our containers are functionally checked and gated per commit on Fedora, CentOS, and Ubuntu. I am experienced as a PTL, leading the Heat Orchestration program from zero LOC through OpenStack integration for 3 development cycles. I write code as a PTL and was instrumental in getting the Magnum Container Service code-base kicked off from zero LOC where Adrian Otto serves as PTL. My past experiences include leading Corosync from zero LOC to a stable building block of High Availability in Linux. Prior to that I was part of a team that implemented Carrier Grade Linux. I have a deep and broad understanding of open source, software development, high performance team leadership, and distributed computing. I would be pleased to serve as PTL for Kolla for the Liberty cycle and welcome your vote. Regards -steve [1] https://wiki.openstack.org/wiki/Kolla/PTL_Elections_March_2015 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
[Yahoo-eng-team] [Bug 1429755] [NEW] Fix difficult log output in nova/nova/network/linux_net.py
Public bug reported: When reloading dnsmasq, this log message Hupping dnsmasq threw ... is a little difficult. ** Affects: nova Importance: Undecided Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: In Progress ** Changed in: nova Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) ** Summary changed: - Fix wrong log output in nova/nova/network/linux_net.py + Fix difficult log output in nova/nova/network/linux_net.py -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1429755 Title: Fix difficult log output in nova/nova/network/linux_net.py Status in OpenStack Compute (Nova): In Progress Bug description: When reloading dnsmasq, this log message Hupping dnsmasq threw ... is a little difficult. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1429755/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1429759] [NEW] Fix wrong log output in nova/nova/tests/unit/fake_volume.py
Public bug reported: When begining detaching volume, this wrong log outout beging detaching volume .. occurs. ** Affects: nova Importance: Undecided Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: In Progress ** Changed in: nova Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1429759 Title: Fix wrong log output in nova/nova/tests/unit/fake_volume.py Status in OpenStack Compute (Nova): In Progress Bug description: When begining detaching volume, this wrong log outout beging detaching volume .. occurs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1429759/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1429775] [NEW] Fix wrong log output in neutron/neutron/agent/linux/dhcp.py
Public bug reported: When all subnets is turnning off dhcp and killing the process, this wrong log output Killing dhcpmasq for network since all subnets have turned off DHCP ... occurs. ** Affects: neutron Importance: Undecided Assignee: SHIGEMATSU Mitsuhiro (pshige) Status: In Progress ** Changed in: neutron Assignee: (unassigned) = SHIGEMATSU Mitsuhiro (pshige) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1429775 Title: Fix wrong log output in neutron/neutron/agent/linux/dhcp.py Status in OpenStack Neutron (virtual network service): In Progress Bug description: When all subnets is turnning off dhcp and killing the process, this wrong log output Killing dhcpmasq for network since all subnets have turned off DHCP ... occurs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1429775/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
10 Sexy Ways to Improve Your Relattionship Sexually
inline: image/png___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: [MP3 ENCODER] 3.84beta is out, default VBR mode = old VBR mode
Hello, everyone. I just upload my Macintosh port at: http://isize.egroups.co.jp/files/lame-dev/ Thanks. -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new common macro
on 00.6.24 0:27 AM, Iwasa Kazmi at [EMAIL PROTECTED] wrote:
lame_errorf() was added in util.c.
I intend to replace fprintf(),printf(),assert() and exit()
with these macros.
That's really what I have been needed! Thanks a lot!
I can easily replace printf() to my GUI error handle function.
For Macintosh,
int StopAlertf(char* format, ...)
{
int status;
va_listlist;
char buf[256];
va_start(list, format);
status = vsprintf(buf, format, list);
va_end(list);
c2pstr(buf);
ParamText((StringPtr)buf, 0, 0, 0);
Alert(1000, 0);
return status;
}
Or for Windoze,
int StopAlertf(char* format, ...)
{
int status;
va_listlist;
char buf[256];
va_start(list, format);
status = vsprintf(buf, format, list);
MessageBox(NULL, buf, "LAME error", MB_OK);
return status;
}
--
Osamu Shigematsu
mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Normalize audio input
Hello, all. I would like to normalize (maxmize) and trim silent part from input audio data. I'm going to add both routine into get_audio.c (I don't use libsndfile). Does anybody know how to do that or such sound libraries? TIA -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] cast problem in takehiro.c
Hello, all. In file takehiro.c, I got following errors. I think unsinged should be changed to int, or all must be casted. Error : cannot convert 'unsigned int *' to 'int *' takehiro.c line 247 return count_bit_noESC(ix, end, 1, s); Error : cannot convert 'unsigned int *' to 'int *' takehiro.c line 251 return count_bit_noESC_from2(ix, end, huf_tbl_noESC[max - 1], s); Error : cannot convert 'unsigned int *' to 'int *' takehiro.c line 257 choice = count_bit_noESC_from3(ix, end, huf_tbl_noESC[max - 1], s); Error : cannot convert 'unsigned int *' to 'int *' takehiro.c line 281 return count_bit_ESC(ix, end, choice, choice2, s); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 369 gi-table_select[2] = choose_table(ix + a2, ix + i, bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 383 gi-table_select[0] = choose_table(ix, ix + a1, bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 384 gi-table_select[1] = choose_table(ix + a1, ix + a2, bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 454 r0t = choose_table(ix, ix + a1, r0bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 462 r1t = choose_table(ix + a1, ix + a2, bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 490 r2t = choose_table(ix + a2, ix + bigv, bits); -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] type mismatch error in quantize-pvt.c line 1088
Hello, Robert. on 00.5.21 8:41 PM, Robert Hegemann at [EMAIL PROTECTED] wrote: Hi, the correct fix looks like this: if (scalefac-l[sfb]0) Oh, thank you. I will replace that code. -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Debianのインストールについて
前略 既にメーリングリストに登録しましたので、質問をしても宜しいですか？ confirm 22061618496594747790863 Hiromasa Shigematsu 若し、その他の手続きが必要ならば、連絡願います。 質問事項： 東芝の６６０ proなるノートＰＣにLinuxをresc1440.binなるfloppy を使用してインストールしていますが。 下記のメッセージが出てＰＣがｒｅｓｅｔされてしまいます。 起動optionの指定で解決出来るのでしょうか？ 以上
[MP3 ENCODER] Macintosh LAME port (based on 3.61 and CocaCoder)
Hello, all. Now I introduce my new Macintosh LAME. It has GUI and users can encode from AIFF, WAVE, and CD audio with easy operation. You can download it at; http://www.ravi.ne.jp/fujibiz/lib/LAME_0127_1715.hqx Pls note, this is eary beta version, so please do not let the end users know this URL. That file is only binary compressed with StuffIt 5.x, not source. I also send a CD ripper code to the auther of Mac BladeEnc. Hope MP3 becomes more popular and easy to use. Thanks. -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] NOPOW define added in CVS...
on 00.1.28 4:00 AM, Sigbj?rn Skj?ret at [EMAIL PROTECTED] wrote: Ok, it seems 68k (040/060) benefits the most from this, because it doesn't have exp/log functions in the FPU, and has to emulate them... AltiVec has exp/log, but no pow. Using Vector Unit is much faster than looking up table. Just guess. No test. -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] calulation speed between float and double
Hi, all. Recently, I found that float (32bit folating point) is faster than double (64bit) when calculating devision. More, division is extreamly slower than multiplication. 750_um.pdf Table 6-7. Floating-Point Instructions (p.272-) fadd 1-1-1fadds 1-1-1 fdiv 31 fdivs 17 fmadd 2-1-1fmadds 1-1-1 fmul 2-1-1fmuls 1-1-1 fsub 1-1-1fsubs 1-1-1 MPC7400UM_prel.pdf fadd 1-1-1fadds 1-1-1 fdiv 31 fdivs 17 fmadd 1-1-1fmadds 1-1-1 fmul 1-1-1fmuls 1-1-1 fsub 1-1-1fsubs 1-1-1 With Metroworks Codewarrior, compiler does not convert division with constants to multiplication, so we had better optimize souce code level. I think, some other C compilers may not optimize in this topic, too. And if we don't add "f" on the end of constants, it will be considered as double, and this caused speed down. float x, y, z; x = y / z / 2.0; /* bad! */ x = y * 0.5f / z; /* good */ x = y / ( z * 2.0f ); But some math libraries may not support float, i.e, negligence. #define sinf(X) (float)sin((double)X) So, without using ANSI math.h in loop heavy, float - double has large overhead, I think using double is no merit. Data size is larger than float so I wonder it may cause cache miss-hit, lower loading/saving RAM - register. And PowerPC G4's vector unit does not support double. And pow(x,y) is much slower than exp(y*log(x)) on Macintosh (with MathLib on OS 9 + G4, and G3). How does everyone think about unifing float size to 32bit? It has merit to x86, or other CPU? -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] calulation speed between float and double
on 00.1.27 6:27 AM, Stefan Bellon at [EMAIL PROTECTED] wrote:
On StrongARM I tried REAL_IS_FLOAT, REAL_IS_LONG_DOUBLE and none of
both. It didn't make any difference in the resulting encoding time.
Greetings,
On my Mac, just retype typedef doublt FLOAT8 to typedef float FLOAT8, it
became little (about 5%) slower.
I guess, the reason may be type missmatch with constans.
There is very few use of math.h functions in LAME, so I think I'm able to
write own fucntions, or replace table reffering.
On my test, sin() in MathLib with float is about 1.5 times slower than
following funtion. (Not same quality. my function is low precise.)
I have not tested with libmoto by Motorola.
FLOAT sin_F(FLOAT x)
{
const static FLOAT p = 3.14159265358979f;
const static FLOAT q = 1.0f / p;
FLOAT x2, tx, s;
int t;
t = (x * q); /* floor() is very slow */
x = x - (t * p); /* make range to -pi/2 x pi/2 */
x2 = x * x;
/* calculate sin(x) */
s = x;
x *= x2; s += x * (FLOAT)-0.17584f; /* prevent overflow +- 1.0 */
x *= x2; s += x * (FLOAT) 0.008333217685101601546200f;
x *= x2; s += x * (FLOAT)-0.000198412698412698412526317115478490f;
x *= x2; s += x * (FLOAT) 0.027557319223985892510950593270458000f;
if ( t 1 ) s = -s;
return s;
}
--
Osamu Shigematsu
mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Creating code resource for Mac
Hi, all. I got a promblem when porting L.A.M.E for Macintosh as REALbasic plugin. The problem is almost of L.A.M.E codes are abruptly quit with calling exit() function. However, I have to return error code and I am not allowed call exit() in the code resource. I know, that GPL must be opened the source, thouth, the work to rewrite all functions to return error, don't call exit() is troublesome job and to give them comments of changings are more nuisance thing for me. So, I wonder, how can I make L.A.M.E does not quit abruptly with exit(). I think I could check errors with stderr file. Or is there any port for DLLs which return an error code, never quit in the L.A.M.E.? -- Osamu Shigematsu http://www.ravi.ne.jp/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] twinvq
Hello. TwinVQ is a technology by NTT, I thought, and VQ means vector quantazation. Threrefore, YAMAHA's SoundVQ may be same as TwinVQ. Please check out following URIs. http://www.wnn.or.jp/wnn-sound/twinvq/index.html http://www.yamaha.co.jp/xg/SoundVQ/ HTH. on 99.11.25 4:05 PM, Ampex at [EMAIL PROTECTED] wrote: this is a completely mp3 listserv, but in case any of you dont know about twinvq, its another natural audio codec with better frequency response than mp3 at the same bitrate. http://www.vqf.com, http://www.vqcentral.com, and channel #vqf on the DALnet IRC network (irc.dal.net), are good places to check it out. -- Osamu Shigematsu http://www.ravi.ne.jp/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re : [MP3 ENCODER] 32K limit (was Greetings)
Hello, Lionel.
on 99.11.9 6:18 PM, Lionel Bonnet at [EMAIL PROTECTED] wrote:
The 32K limit doesn't really exists on PowerPC : in each application memory
zone, you have the stack zone and the heap zone.There is a default stack
zone(32 K)but if you want to increase it, you must change the limit of the
heap, and so the limit of the stack.
So you must insert this code at the very beginning of the application :
stkNeeded=StackNeeded();
if (stkNeeded StackSpace())
{
SetApplLimit((Ptr) ((long) GetApplLimit() - stkNeeded + StackSpace()));
}
heapSize = (long) GetApplLimit() - (long) ApplicationZone();
I know, of course, stack meaning, though, this is not such a problem, I
think. We can easily increase stack size with project settings - target -
PPC target - stack size (default 64K) in CW.
I wrote following test code, but could not compile. The line,
char chunk[64*1024L];
is smaller than 128*1024L, and there may be enough remnant of stack,
however, CW tells me "local data is larger than 32K". I do think, locak data
is not equal to stack. Local data may mean local variables in specific
funcion.
How can I break though this limit? I ask this in general macintosh
programming mailing list, people says, "There is no way. Make it global or
static."
Do I misunderstand?
TIA.
#include string.h /* for memset */
#include Types.h
#include Memory.h
#include Quickdraw.h
#include Fonts.h
#include Events.h
#include Menus.h
#include Windows.h
#include TextEdit.h
#include Dialogs.h
#include OSUtils.h
#include ToolUtils.h
#include SegLoad.h
#include Sound.h
void Initialize(void);
int main(void)
{
long stkNeeded /*, heapSize */;
Initialize();
stkNeeded = 128*1024L; /* StackNeeded(); */
if (stkNeeded StackSpace())
{
SetApplLimit((Ptr) ((long) GetApplLimit() - stkNeeded +
StackSpace()));
}
/* heapSize = (long) GetApplLimit() - (long) ApplicationZone(); */
do {
} while (!Button());
return 0;
}
void Initialize(void)
{
InitGraf(qd.thePort);
InitFonts();
InitWindows();
InitMenus();
TEInit();
InitDialogs(nil);
InitCursor();
}
void foo(void)
{
char chunk[64*1024L];
memset(chunk, 0x00, 64*1024L);
}
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Greetings
Hello, Ben. on 99.11.8 5:01 PM, "Ben \"Jacobs\"" at [EMAIL PROTECTED] wrote: 1. In C/C++ Language settings panel, try disabling "ANSI Strict". I think that will allow you to compile the //-style comments. I also solve this way, though, this is not good solution. The best way is to fix source codes are not used // style comments by auther. Otherwise, every thime when updated the code, I have to edit // to /* */. 2. To solve the problem of local data 32k in file "lame.c", I moved the large arrays outside the local function. In other words, I made them global within the file. I insert the keyword "static". I wonder if this change makes encording speed to slow or not. The files which I changed from LAME to make MacLAME 3.37 are on my website now: Thanks. I will check it later. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 32K limit (was Greetings)
Hello, Mark.
on 99.11.9 10:29 AM, Mark Taylor at [EMAIL PROTECTED] wrote:
I've got so many patches which change all the c++ comments to c style,
I finally gave in and got rid of all the //'s :-)
Thank you very much for your job!
2. To solve the problem of local data 32k in file "lame.c", I moved the
large arrays outside the local function. In other words, I made them
global within the file.
What kind of compiler would have a 32k limit for data on the stack???
The Amiga seemed to have this problem, but you could set some option
to increase the limit.
I don't know why this limit exists on PowerPC machines, though, both
Metroworks CodeWarrior and MPW (Free C/C++ Development environment by Apple)
have this limit. Known by reports on other Japanese mailing list, MPW has
critial bug obtaining large stack more than 32K. (We can compile, but it
will not work.) I don't use MPW so I don't know this is truth or not.
To solve this problem, I put "static" before large array. This is not
important, serious for me. But the codes of LAME have so may globals,
statics, and this makes hard to understanding the flow of prosess to me.
Hope to be changed to use struct (pointers).
And one more suggestion. Macintosh programmers could not use f_open()
function because Macintosh has no full path consept. Windows, or UNIX has a
path, but Macintosh has not. Hard drive name is not specified and it can be
easy changed. Of course, file name may be contain spaces.
So don't use file name to specify the file. Hope to use FILE* to specify the
input/output file. With this change, I will be able to port LAME easiler.
ie.
typedef struct input_t
{
char* file; /* file name */
FILE* fp; /* file pointer */
/* and so on... */
} input_t;
typedef struct confing_t
{
input_t* input;
output_t* output;
VBR_t* VBR;
ID3_t* ID3;
/* and so on... */
} config_t;
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Greetings
Hello, LAME developers.
This is the first time for me to post the message to this community. So
please let me allow introduce myself. My name is Osamu Shigematsu, and now
porting LAME to Macintosh. My work had done and now optimizing the code for
Macintosh.
I'm newbie, though, I uploaded both binary and compleate source code with
codewarrior pro 5 (macintosh c/c++ popular IDE from metroworks) to hope
being someone's help. I know patent problem, so I wrote an e-mail to IIS and
Thomson multimedia that I upladed the stuffs.
BTW, I wonder if why the buffer for mp3 encorder is buffer[2][1152].
So we have to copy from insamp to buffer and the order is deffernt from
both, I can not use memcpy to copy the memory block. (of course, this is
terrible waste of the time, just pass buffer pointer to the read_samples
subroutine)
Does anyone know the reason? TIA.
/* this code from get_audio.c but modified to my style */
int
get_audio( short buffer[2][1152], int stereo, layer* info )
{
int j;
short insamp[1152][2];
int samples_read;
int framesize, samples_to_read;
static unsigned long num_samples_read;
unsigned long remaining;
if ( frameNum == 0 ) {
num_samples_read = 0;
num_samples = GetSndSamples();
}
remaining = num_samples - num_samples_read;
framesize = ( info-version == 0 ) ? 576 : 1152;
samples_to_read = ( remaining framesize ) ? framesize : remaining;
if ( samples_to_read 0 )
samples_to_read = 0;
if ( input_format == sf_mp3 ) {
DebugStr( "\psf_mp3 is not supported!" ); /* call debugger to draw
string (macintosh only!!) */
}
else
{
/* MPEG 1 */
if ( stereo == 2 )
{
samples_read = read_samples( (short*)insamp, 2*framesize,
2*samples_to_read );
samples_read /= 2;
for( j = 0; j framesize; j++ )
{
buffer[0][j] = insamp[j][0];
buffer[1][j] = insamp[j][1];
}
}
else
{
if ( autoconvert != FALSE ) /* autoconvert == TRUE */
{
/* downconvert from a stereo file into a mono buffer */
samples_read = read_samples( (short*)insamp, 2*framesize,
2*samples_to_read );
samples_read /=2;
for( j = 0; j framesize; j++ )
{
/* dont overflow the short int */
buffer[0][j] = ((long)insamp[j][0] +
(long)insamp[j][1])/2;
buffer[1][j] = 0;
}
}
else
{
samples_read = read_samples( (short*)insamp, framesize,
samples_to_read );
for( j = 0; j framesize; j++ )
{
buffer[0][j] = insamp[j][0];
buffer[1][j] = 0;
}
}
}
}
/* dont count things in this case to avoid overflows */
if ( num_samples != ULONG_MAX /* MAX_U_32_NUM */ ) /* limits.h */
num_samples_read += samples_read;
return( samples_read );
}
--
Osamu Shigematsu
http://www.ravi.ne.jp/
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
